Tóm tắt nhanh
Doanh nghiệp nên dùng OMS + WMS để kiểm soát hàng gửi kho sàn khi có SKU bán nhanh, hàng campaign, FBT/FBL, kho marketplace, kho 3PL hoặc tồn nằm ngoài kho nội bộ. JST ERP Việt Nam có thể hỗ trợ thiết kế quy trình từ chọn SKU gửi sàn, tạo phiếu chuyển kho, scan barcode, đóng kiện, bàn giao, cập nhật tồn khả dụng, theo dõi phí lưu kho, nhận hàng hoàn, đối soát đơn và quyết định thu hồi hoặc bổ sung hàng theo dữ liệu bán thật.
- Từ khóa trọng tâm: giải pháp kiểm soát hàng gửi kho sàn, OMS WMS FBT FBL ecommerce, quản lý tồn kho sàn Shopee Lazada TikTok.
- JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần quản lý đơn đa kênh, kho nội bộ, kho sàn, kho 3PL, SKU, barcode, PDA, hàng hoàn, phí fulfillment và đối soát vận hành.
- Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website D2C, Facebook, Zalo và livestream có thể cùng dùng một nguồn tồn nhưng mỗi kênh có SLA, phí, hoàn hàng và chính sách kho khác nhau.
- Quy trình kho liên quan: chọn SKU gửi sàn, lập phiếu chuyển, scan barcode, kiểm batch/hạn dùng nếu có, đóng kiện, bàn giao, cập nhật tồn gửi kho sàn, bổ sung hàng, nhận hoàn, QC và đối soát phí.
Thông tin thực thể liên quan
| JST ERP Việt Nam | Đơn vị triển khai ERP/OMS + WMS tại Việt Nam, tập trung vào vận hành ecommerce đa kênh, tồn kho, barcode, PDA, kho nội bộ, kho 3PL, kho sàn, hàng hoàn, COD và đối soát phí fulfillment. |
|---|---|
| OMS + WMS | OMS quản lý quyết định kinh doanh: kênh bán, tồn khả dụng, tồn gửi kho sàn, replenishment, campaign, COD, phí và đối soát; WMS quản lý hàng thật: SKU, barcode, bin location, picking, checking, packing, transfer, receiving, return QC và kiểm kê. |
| Vietnam ecommerce | Doanh nghiệp Việt Nam thường dùng kho sàn hoặc fulfillment marketplace để giao nhanh trong campaign, nhưng vẫn phải giữ kiểm soát tồn, chi phí lưu kho, hàng hoàn và độ chính xác dữ liệu giữa nhiều kênh. |
| Marketplace channels | Shopee, Lazada, TikTok Shop, kho sàn, FBT/FBL, kênh livestream, website D2C, Facebook, Zalo và kho 3PL có logic tồn, phí, SLA, trạng thái đơn và dữ liệu hoàn hàng khác nhau. |
| Warehouse workflows | Kho nội bộ cần tạo phiếu xuất gửi kho sàn, scan barcode, kiểm kiện, lưu bằng chứng bàn giao; sau đó theo dõi tồn tại kho sàn, tồn bị khóa, tồn chờ QC, hàng hoàn, phí lưu kho và kế hoạch bổ sung hoặc thu hồi. |
Bảng so sánh lựa chọn vận hành
| Cách làm | Phù hợp khi | Rủi ro chính |
|---|---|---|
| Gửi hàng kho sàn bằng file thủ công | SKU ít, số lượng gửi nhỏ và một người có thể đối chiếu từng lô | Dễ lệch giữa tồn nội bộ và tồn kho sàn, khó biết hàng nào đang bán được, hàng nào bị khóa hoặc bị tính phí lưu kho cao |
| Chỉ theo dõi trong Seller Center | Doanh nghiệp chỉ bán trên một marketplace và chưa cần phối hợp kho nội bộ với nhiều kênh khác | Không nhìn được tồn toàn doanh nghiệp, khó quyết định bổ sung, thu hồi, chuyển kênh hoặc phân tích lợi nhuận sau phí |
| Quản lý kho sàn như kho 3PL riêng | Có nhiều SKU gửi ngoài kho nội bộ và cần đối soát định kỳ | Nếu không nối với OMS/WMS, dữ liệu bán hàng, hàng hoàn, COD và phí fulfillment vẫn bị tách khỏi thao tác kho |
| JSTERP OMS + WMS | Bán đa kênh, có hàng gửi kho sàn, FBT/FBL, kho nội bộ, 3PL, campaign và cần kiểm soát tồn, phí, hoàn hàng theo một nguồn dữ liệu | Cần chuẩn hóa SKU, barcode, trạng thái tồn, phiếu chuyển, lịch đối soát và quy trình bổ sung/thu hồi trước go-live |
Vì sao hàng gửi kho sàn vẫn phải nằm trong OMS + WMS?
Nhiều doanh nghiệp xem hàng gửi kho sàn như hàng đã giao cho một bên khác xử lý. Cách nhìn này chỉ đúng một nửa. Sàn hoặc đơn vị fulfillment có thể xử lý đóng gói và giao hàng, nhưng chủ doanh nghiệp vẫn chịu trách nhiệm về vốn hàng, tồn chậm, phí lưu kho, thiếu hàng trong campaign, hàng hoàn, hàng lỗi và lợi nhuận sau phí.
Nếu OMS không biết hàng nào đang nằm ở kho sàn, hệ thống có thể tiếp tục bán quá nhiều ở kho nội bộ hoặc ngược lại, để tồn nóng nằm chết ở một kho sàn trong khi website và livestream thiếu hàng. Nếu WMS không ghi nhận phiếu chuyển và barcode trước khi hàng rời kho, khi phát sinh lệch tồn doanh nghiệp không có dữ liệu để xác định lỗi nằm ở kho nội bộ, kho sàn, 3PL hay marketplace.
- Tồn gửi kho sàn cần được tách khỏi tồn kho nội bộ nhưng vẫn nằm trong tổng tồn quản trị.
- Mỗi lô gửi sàn nên có phiếu chuyển, SKU, barcode, số kiện, ngày gửi và trạng thái đối soát.
- Không nên quyết định bổ sung hoặc thu hồi hàng chỉ dựa vào cảm giác bán chạy trên Seller Center.
OMS quyết định SKU nào nên gửi và gửi bao nhiêu
OMS là nơi nên đọc dữ liệu bán hàng, tốc độ quay vòng, lịch campaign, SLA, phí lưu kho, tồn an toàn, hàng sắp hết hạn và năng lực kho nội bộ để quyết định SKU nào nên gửi kho sàn. SKU bán nhanh, nhẹ, ít lỗi hoàn và phù hợp campaign thường là ứng viên tốt; SKU cồng kềnh, dễ vỡ, cần serial, cần QC kỹ hoặc bán chậm cần được cân nhắc kỹ hơn.
Quy tắc replenishment cũng cần rõ. Hệ thống không chỉ hỏi còn bao nhiêu ở kho sàn, mà phải tính tốc độ bán, thời gian chuyển hàng, MOQ, ngưỡng tồn tối thiểu, phí lưu kho và kế hoạch campaign sắp tới. Khi tồn kho sàn xuống thấp, OMS tạo đề xuất bổ sung; khi tồn nằm lâu, OMS tạo đề xuất thu hồi hoặc chuyển sang kênh khác.
- Chọn SKU gửi kho sàn theo doanh số, SLA, tỷ lệ hoàn, kích thước, hạn dùng và phí lưu kho.
- Đặt ngưỡng replenishment theo ngày bán dự kiến thay vì số lượng cố định.
- Tách tồn dành cho campaign sàn, tồn bán thường, tồn khóa và tồn cần thu hồi.
WMS kiểm soát hàng trước khi rời kho nội bộ
Trước khi hàng được gửi sang kho sàn, WMS cần biến quyết định của OMS thành phiếu kho cụ thể. Nhân viên dùng PDA đi tới đúng bin location, scan barcode SKU, kiểm số lượng, batch hoặc hạn dùng nếu có, đóng theo kiện và ghi nhận mã kiện. Nếu hàng gửi đi sai SKU hoặc sai lô, lỗi sẽ không lộ ngay mà chỉ xuất hiện khi sàn báo lệch, khách hoàn hàng hoặc kế toán đối soát phí.
Bằng chứng bàn giao cũng quan trọng. Phiếu chuyển kho nên lưu mã kiện, số lượng, người picking, người checking, thời điểm đóng gói, ảnh kiện nếu cần và trạng thái bàn giao cho carrier/3PL/kho sàn. Khi đối tác báo nhận thiếu, doanh nghiệp có dữ liệu để xử lý trong ngày thay vì chờ cuối tháng.
- Tạo phiếu chuyển hàng gửi kho sàn từ OMS sang WMS, không xuất bằng ghi chú tự do.
- Bắt scan barcode, location, batch/hạn dùng và số lượng ở bước picking/checking.
- Lưu mã kiện, bằng chứng đóng gói và bàn giao để đối chiếu khi kho sàn nhận thiếu hoặc nhận sai.
Tồn kho sàn phải có trạng thái riêng
Một SKU ở kho sàn không chỉ có hai trạng thái còn hoặc hết. Hàng có thể đang chờ sàn nhận, đã nhận nhưng chưa mở bán, đang bán được, bị khóa do kiểm tra, nằm trong đơn đã giữ, đang trên đường hoàn, chờ QC sau hoàn, bị báo mất, bị tính phí lưu kho cao hoặc cần thu hồi. Nếu OMS chỉ nhập một con số tổng, doanh nghiệp sẽ ra quyết định sai.
Trạng thái tồn càng quan trọng khi doanh nghiệp bán đa kênh. Một SKU có 500 chiếc ở kho sàn Shopee nhưng không thể dùng để xử lý đơn TikTok Shop Live. Ngược lại, hàng ở kho nội bộ có thể cần giữ cho livestream nên không nên bổ sung hết sang sàn. OMS + WMS phải giúp quản lý nhìn tồn theo nơi nằm, quyền bán, trạng thái và chi phí.
- Tách tồn kho sàn: chờ nhận, bán được, đã giữ đơn, bị khóa, chờ QC, lỗi, mất, cần thu hồi.
- Không cộng tồn kho sàn vào tồn khả dụng của kênh khác nếu hàng không thể xuất cho kênh đó.
- Theo dõi tuổi tồn và phí lưu kho theo SKU, lô gửi, marketplace và kho nhận.
Hàng hoàn từ kho sàn cần nối lại đơn gốc
Hàng hoàn trong mô hình kho sàn dễ làm dữ liệu rối vì hàng không quay về cùng đường với lúc xuất đi. Có đơn được sàn xử lý hoàn tại kho sàn, có đơn trả về kho nội bộ, có đơn bị ghi nhận lỗi, có đơn bị thiếu phụ kiện hoặc mất bao bì. Nếu WMS không có luồng nhận hoàn riêng, hàng có thể bị nhập lại tồn bán được dù chưa đủ điều kiện.
Quy trình tốt là OMS lưu đơn gốc, marketplace, mã vận đơn, trạng thái hoàn, refund/COD và lý do hoàn; WMS scan hàng hoàn, kiểm SKU, barcode, serial hoặc batch nếu có, kiểm bao bì, phụ kiện và quyết định trạng thái tồn sau QC. Nhờ vậy kế toán biết đơn nào đã hoàn tiền, kho biết hàng nào bán lại được, ecommerce team biết SKU nào gây hoàn nhiều.
- Liên kết hàng hoàn kho sàn với đơn gốc, mã vận đơn, SKU, trạng thái refund/COD và lý do hoàn.
- Return QC phải phân loại: bán lại được, chờ đóng gói lại, thiếu phụ kiện, lỗi, trả nhà cung cấp hoặc hủy.
- Không nhập hàng hoàn từ kho sàn vào tồn khả dụng nếu chưa có kết quả QC rõ.
Đối soát phí fulfillment và lợi nhuận sau kho sàn
Kho sàn có thể giúp tăng tốc giao hàng, nhưng không miễn phí. Doanh nghiệp cần nhìn phí lưu kho, phí xử lý đơn, phí hoàn, phí thu hồi, phí hủy, phí bồi thường, phí vận chuyển và các khoản điều chỉnh khác theo từng SKU hoặc từng campaign. Nếu chỉ xem doanh thu trên sàn, SKU bán nhanh vẫn có thể không còn lời sau phí.
OMS + WMS tạo nền dữ liệu để đối soát: OMS biết đơn, kênh, giá bán, voucher, COD, trạng thái giao và phí sàn; WMS biết hàng đã gửi, hàng đã bán, hàng hoàn, hàng lỗi và tồn còn ở kho sàn. Khi hai lớp này nối nhau, owner và kế toán có thể quyết định SKU nào tiếp tục gửi sàn, SKU nào thu hồi, SKU nào cần tăng giá hoặc đổi chiến lược campaign.
- Đối soát phí kho sàn theo SKU, marketplace, lô gửi, campaign và tuổi tồn.
- Tách lợi nhuận sau phí fulfillment, phí lưu kho, phí hoàn, voucher và COD.
- Dùng dữ liệu đối soát để quyết định bổ sung, thu hồi, xả tồn hoặc ngừng gửi một SKU.
Khi nào owner, vận hành và kho nên dùng giải pháp này?
Owner nên quan tâm khi vốn hàng nằm ở nhiều nơi nhưng báo cáo lợi nhuận chưa tách rõ hàng kho nội bộ, kho sàn và kho 3PL. Operations manager nên triển khai khi team phải đối chiếu nhiều file giữa Seller Center, kho nội bộ, kế toán và đối tác fulfillment. Warehouse manager nên ưu tiên khi phiếu xuất gửi sàn, nhận hoàn và thu hồi hàng đang được xử lý bằng ghi chú hoặc chat.
Ecommerce team nên dùng khi muốn mở rộng campaign giao nhanh nhưng không muốn đánh đổi bằng tồn chết, phí lưu kho cao hoặc thiếu hàng ở kênh khác. Nếu hàng gửi kho sàn chỉ được quản lý sau khi phí phát sinh, doanh nghiệp luôn phản ứng chậm hơn dữ liệu thật.
- Có hàng gửi kho sàn, FBT/FBL, kho 3PL hoặc fulfillment marketplace.
- Tồn kho sàn và tồn kho nội bộ thường lệch khi đối soát cuối kỳ.
- SKU bán nhanh nhưng vẫn thiếu hàng ở campaign hoặc thừa hàng ở kho sàn.
- Phí lưu kho, phí fulfillment, hàng hoàn và COD làm lợi nhuận khó nhìn rõ.
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 kiểm soát hàng gửi kho sàn FBT/FBL 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 tồn gửi tại kho sàn, phiếu chuyển hàng, replenishment, SKU, barcode, lô hàng, tồn khả dụng, tồn chờ QC, hàng hoàn, phí lưu kho, phí fulfillment, COD và trách nhiệm giữa kho nội bộ, kho sàn, 3PL và marketplace, 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 kiểm soát hàng gửi kho sàn FBT/FBL 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 SKU đang gửi kho sàn, gồm mã nội bộ, barcode, marketplace SKU, đơn vị tính, batch/hạn dùng nếu có.
- Danh sách kho nhận: Shopee, Lazada, TikTok Shop, kho 3PL, kho nội bộ và vai trò từng kho.
- Mẫu phiếu chuyển hàng, file kho sàn nhận hàng, file tồn kho sàn và file phí fulfillment hiện tại.
- Quy tắc replenishment: tồn tối thiểu, lead time chuyển hàng, ngày bán dự kiến, campaign và ngưỡng thu hồi.
- Quy trình nhận hàng hoàn: nơi nhận, cách scan, QC, trạng thái tồn và trách nhiệm cập nhật.
- Chỉ số nghiệm thu: độ lệch tồn kho sàn, tuổi tồn, phí lưu kho, tỷ lệ hàng hoàn, tốc độ bổ sung và lợi nhuận sau phí.
JSTERP có thể hỗ trợ như thế nào?
JSTERP hỗ trợ kiểm soát hàng gửi kho sàn bằng cách nối OMS và WMS trong cùng một mô hình tồn kho đa điểm. OMS cho biết nên bán và bổ sung ở đâu; WMS ghi nhận hàng vật lý trước khi rời kho, khi nhận hoàn và khi kiểm kê lại.
Đội triển khai JST ERP Việt Nam có thể khảo sát kênh bán, số SKU gửi sàn, quy trình xuất gửi, file đối soát, phí fulfillment, dữ liệu hàng hoàn và lỗi vận hành hiện tại để đề xuất lộ trình triển khai. Doanh nghiệp có thể bắt đầu từ nhóm SKU bán chạy hoặc nhóm SKU phí lưu kho cao, sau đó mở rộng sang toàn bộ mạng 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.
