Giải pháp đối soát voucher, phí sàn và lợi nhuận SKU sau campaign bằng OMS + WMS

Tóm tắt nhanh

Doanh nghiệp nên dùng giải pháp này khi campaign tạo nhiều đơn nhưng sau đó khó biết SKU nào thật sự có lời. Phạm vi cần kiểm soát gồm giá bán sau voucher, mã khuyến mãi, phí sàn, phí thanh toán, COD, phí vận chuyển, trợ giá, quà tặng, chi phí bao bì, SKU xuất kho, hàng hoàn, đơn hủy, đơn giao thất bại và tồn trả về sau QC. Chủ doanh nghiệp, operations manager, ecommerce team và kế toán nên xem đối soát sau campaign là một quy trình OMS + WMS, không chỉ là thao tác tải báo cáo cuối tháng.

• Từ khóa trọng tâm: giải pháp đối soát voucher phí sàn, đối soát lợi nhuận SKU sau campaign, OMS WMS đối soát phí sàn ecommerce.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần gom đơn đa kênh, kiểm soát SKU, kho, barcode, hàng hoàn, COD, chi phí vận hành và báo cáo lợi nhuận theo dữ liệu thật.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, livestream, website và social commerce thường có nhiều loại voucher, phí sàn, trạng thái thanh toán và chính sách hoàn tiền khác nhau.
• Quy trình kho liên quan: SKU master, barcode, picking, checking, packing, vật tư đóng gói, mã kiện, bàn giao vận chuyển, đơn giao thất bại, hàng hoàn chờ QC và nhập lại tồn.

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

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

Vì sao campaign doanh thu cao vẫn có thể lỗ?

Trong ecommerce, doanh thu gộp không phải là lợi nhuận. Một đơn hàng có thể bị trừ voucher shop, phí nền tảng, phí thanh toán, phí vận chuyển chênh lệch, phí hoàn, chi phí bao bì và chi phí xử lý kho. Nếu sản phẩm còn đi kèm quà tặng hoặc bundle nhiều SKU, lợi nhuận của từng SKU càng khó nhìn thấy bằng báo cáo doanh thu đơn giản.

Sai lệch thường xuất hiện sau campaign lớn. Team ecommerce nhìn doanh số theo kênh, kế toán nhìn file thanh toán, kho nhìn số kiện đã xuất và CSKH nhìn danh sách hàng hoàn. Nếu các dữ liệu này không được nối bằng cùng mã đơn, mã vận đơn, SKU và trạng thái, doanh nghiệp không biết nguyên nhân lỗ nằm ở giá bán, phí sàn, vận chuyển, hàng hoàn hay thao tác kho.

• Doanh thu sau voucher cần tách rõ voucher shop, voucher sàn và trợ giá.
• Lợi nhuận SKU cần trừ phí sàn, phí thanh toán, chi phí vận chuyển và chi phí vận hành liên quan.
• Hàng hoàn và đơn giao thất bại phải quay lại báo cáo lợi nhuận, không chỉ nằm ở báo cáo kho.

OMS cần giữ dữ liệu phí và trạng thái đơn ngay từ đầu

OMS là nơi nên gom dữ liệu đơn từ Shopee, Lazada, TikTok Shop, website, livestream và social commerce. Với mỗi đơn, hệ thống cần lưu giá niêm yết, giá bán thực thu, loại voucher, mã campaign, phí sàn, phí thanh toán, COD, trạng thái thanh toán, trạng thái vận chuyển, mã vận đơn và lý do hủy hoặc hoàn.

Nếu các trường này chỉ được tải về sau bằng file riêng, đội vận hành sẽ mất dấu tại thời điểm ra quyết định. Ví dụ, cùng một SKU bán mạnh trên TikTok Shop có thể có lợi nhuận khác hẳn trên Shopee nếu voucher shop, phí affiliate hoặc phí vận chuyển bị tính khác. OMS giúp chuẩn hóa cách nhìn để không so sánh lệch giữa các kênh.

• Mapping mã đơn marketplace về một mã đơn nội bộ để truy vết.
• Gắn campaign, voucher, kênh bán và trạng thái thanh toán vào từng đơn.
• Tách đơn đã giao, đơn hủy, đơn giao thất bại, đơn hoàn và đơn đang bị giữ thanh toán.

WMS xác nhận chi phí vận hành thật phía sau mỗi đơn

WMS không chỉ phục vụ xuất kho nhanh hơn. Trong đối soát lợi nhuận, WMS chứng minh đơn đã xuất SKU nào, số lượng bao nhiêu, barcode nào được scan, kiện nào được đóng, vật tư đóng gói nào được dùng và đơn có phát sinh lỗi picking, checking, packing hay không. Đây là dữ liệu mà báo cáo sàn không thể cung cấp đầy đủ.

Khi hàng hoàn về kho, WMS cần ghi rõ hàng còn bán được, hàng chờ QC, hàng lỗi, thiếu phụ kiện, sai serial, móp hộp hoặc đã mất niêm phong. Một SKU tưởng đã bán có lời có thể chuyển thành lỗ nếu tỷ lệ hoàn cao hoặc hàng trả về không nhập lại tồn bán được. Vì vậy hàng hoàn phải nối ngược về đơn gốc và campaign gốc.

• Quét barcode khi picking và checking để chắc SKU xuất ra đúng với đơn.
• Ghi nhận vật tư packing, cân nặng, kích thước kiện và ảnh bằng chứng khi cần.
• Nhập hàng hoàn theo trạng thái QC thay vì cộng thẳng vào tồn khả dụng.

Khi nào nên dùng giải pháp đối soát sau campaign?

Chủ doanh nghiệp nên dùng giải pháp này khi doanh thu campaign tăng nhưng dòng tiền, lợi nhuận và tồn kho sau campaign không rõ ràng. Ecommerce manager nên dùng khi cần quyết định SKU nào tiếp tục đẩy voucher, SKU nào phải tăng giá, SKU nào nên giảm tồn và kênh bán nào đang ăn nhiều phí nhất.

Operations manager và quản lý kho nên quan tâm khi campaign tạo áp lực xuất hàng lớn, nhiều đơn hoàn, nhiều kiện giao thất bại hoặc nhiều tranh chấp thiếu hàng. Kế toán nên quan tâm khi file thanh toán sàn, COD, phí vận chuyển và báo cáo kho không khớp nhau, làm quá trình khóa số kéo dài.

• Doanh nghiệp bán đa kênh và thường chạy flash sale, mega sale hoặc livestream.
• Có nhiều SKU biên lợi nhuận mỏng, combo, quà tặng hoặc voucher phức tạp.
• Muốn ra quyết định giá, tồn, campaign và nhập hàng dựa trên lợi nhuận thật thay vì doanh thu gộp.

Báo cáo nên đọc theo SKU, kênh bán và trạng thái hoàn hàng

Báo cáo sau campaign không nên chỉ có tổng doanh thu. Doanh nghiệp cần xem từng SKU theo kênh bán, số đơn, số lượng xuất, doanh thu sau voucher, phí sàn, phí vận chuyển, chi phí bao bì, số lượng hoàn, tỷ lệ hoàn, tồn còn lại, tồn chờ QC và lợi nhuận gộp ước tính. Khi dữ liệu đủ chi tiết, quyết định nhập hàng và chạy voucher sẽ chính xác hơn.

Một cách đọc hữu ích là tách SKU thành ba nhóm: SKU bán tốt và có lời, SKU bán tốt nhưng lỗ do phí/voucher/hoàn cao, SKU bán chậm nhưng đang chiếm tồn kho. Nhóm thứ hai thường là nơi doanh nghiệp mất tiền âm thầm nhất, vì dashboard doanh thu làm sản phẩm đó trông rất hấp dẫn.

• So sánh lợi nhuận cùng SKU giữa Shopee, Lazada, TikTok Shop và livestream.
• Tách đơn đã giao thành công khỏi đơn đang bị giữ thanh toán, đang hoàn hoặc đang tranh chấp.
• Gắn hàng hoàn sau QC về đúng campaign để không đánh giá sai hiệu quả đợt bán.

Checklist triển khai đối soát voucher, phí sàn và lợi nhuận SKU

Trước khi triển khai, doanh nghiệp cần thống nhất công thức lợi nhuận gộp vận hành: doanh thu thực thu trừ voucher shop, phí sàn, phí thanh toán, phí vận chuyển doanh nghiệp chịu, giá vốn, quà tặng, bao bì và chi phí hoàn liên quan. Không nhất thiết mọi chi phí đều được phân bổ hoàn hảo ngay ngày đầu, nhưng quy tắc phải rõ và nhất quán.

Giai đoạn chạy thử nên lấy một campaign thật đã kết thúc để đối chiếu. Chọn 20 đến 50 đơn gồm đơn giao thành công, đơn COD, đơn hoàn, đơn giao thất bại, đơn có voucher lớn, đơn combo, đơn có quà tặng và đơn bị giữ thanh toán. Nếu hệ thống khớp được các tình huống này, báo cáo sau campaign sẽ đáng tin hơn nhiều so với file tổng hợp thủ công.

• Chuẩn hóa SKU master, barcode, combo, quà tặng và mapping kênh bán.
• Xác định trường phí cần lấy từ từng marketplace và cách phân bổ về đơn/SKU.
• Kết nối trạng thái WMS: đã pick, đã check, đã pack, đã bàn giao, hoàn về, QC xong, nhập lại tồn.
• Thiết lập báo cáo theo campaign, SKU, kênh bán, kho xuất, trạng thái giao hàng và trạng thái hoàn.

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 đối soát voucher, phí sàn và lợi nhuận SKU sau campaign 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 nối dữ liệu campaign, voucher, phí sàn, COD, phí vận chuyển, hàng hoàn, chi phí đóng gói, SKU xuất kho và lợi nhuận gộp theo từng đơn hàng để biết sản phẩm nào bán nhiều nhưng không có lời, 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 đối soát voucher, phí sàn và lợi nhuận SKU sau campaign 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

• Chuẩn bị danh sách campaign cần phân tích: thời gian, kênh bán, SKU, voucher và mã chương trình.
• Xuất ví dụ đơn thật gồm đơn giao thành công, COD, hoàn hàng, giao thất bại, combo, quà tặng và đơn bị giữ thanh toán.
• Kiểm tra SKU, barcode, mapping kênh bán, giá vốn, quà tặng, vật tư đóng gói và quy tắc phân bổ chi phí.
• Xác định ai chịu trách nhiệm xác nhận dữ liệu: ecommerce, kho, kế toán, CSKH và quản lý vận hành.
• Đặt chỉ số nghiệm thu: tỷ lệ đơn đối soát được, số lệch phí còn lại, thời gian khóa số sau campaign và lợi nhuận SKU có thể ra quyết định.

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

JSTERP hỗ trợ doanh nghiệp đặt đối soát sau campaign vào cùng một luồng OMS + WMS: đơn hàng đi vào OMS, thao tác kho được WMS xác nhận, hàng hoàn được QC theo trạng thái và báo cáo quản trị đọc lại theo SKU, kênh bán, campaign và lợi nhuận gộp.

Đội triển khai JST ERP Việt Nam có thể cùng doanh nghiệp rà soát dữ liệu Shopee, Lazada, TikTok Shop, website, livestream, quy trình kho, barcode, hàng hoàn và công thức phân bổ chi phí để xây dựng báo cáo phù hợp với cách vận hành thực tế.

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.