Tồn kho khả dụng trên website trả lời câu hỏi “còn bao nhiêu để nhận đơn mới”, khác với số hàng đang nằm trong kho. Nếu website lấy thẳng số lượng trên kệ để hiện “còn hàng”, doanh nghiệp có thể nhận thêm đơn cho phần hàng đã giữ cho khách khác hoặc đang chờ kiểm tra.
Muốn giảm tình trạng bán vượt tồn, cần thống nhất cách tính số được bán, thời điểm giữ hàng và cách trả lại số lượng khi đơn thay đổi. Đây là quyết định nghiệp vụ trước khi là việc nối API. Đồng bộ rất nhanh vẫn có thể đưa lên website một con số sai ý nghĩa.
Tồn kho khả dụng khác tồn thực tế ở đâu?
Tồn thực tế phản ánh hàng có tại một địa điểm theo phạm vi ghi nhận. Trong số đó, một phần có thể đã cam kết cho đơn khác, đang kiểm tra chất lượng hoặc được giữ riêng theo chính sách. Phần có thể nhận bán mới cần loại trừ các lượng không được phép bán, theo định nghĩa thống nhất của doanh nghiệp.
Không nên dùng từ “còn hàng” cho cả hàng đang vận chuyển về và hàng có thể xuất ngay. Nếu nhận đặt trước, hãy trình bày đó là lựa chọn riêng với thời gian dự kiến và điều kiện xác nhận. Người mua cần biết họ đang đặt hàng sẵn hay gửi yêu cầu chờ hàng.
Tài liệu trạng thái tồn kho của Shopify tách on hand, available, committed, unavailable và incoming. Cách phân biệt này hữu ích khi rà soát thuật ngữ, nhưng không có nghĩa ERP hoặc WMS của doanh nghiệp dùng đúng những tên và công thức tương tự.
Bài tổng quan về quản lý kho trên website và phạm vi WMS giúp chọn lớp hệ thống cần dùng. Ở bước chi tiết hơn, doanh nghiệp phải chốt từng trường số lượng: nguồn nào giữ, ai được điều chỉnh và số đó đại diện cho mặt hàng, biến thể hay từng kho.
Chốt cách tính trước khi hiển thị số lượng
Một mô hình minh họa đơn giản: tại một kho có 100 sản phẩm, 25 đã giữ cho đơn được chấp nhận, 10 đang kiểm tra và 5 dành làm mức dự phòng. Nếu bốn nhóm này tách biệt và chưa có ràng buộc khác, lượng có thể nhận bán mới là 60. Đây là số giả định để giải thích cách tính, không phải dữ liệu khách hàng.
Điểm dễ sai là trừ cùng một lượng hai lần. Nếu hệ thống nguồn đã loại hàng kiểm tra và dự phòng khỏi trường “khả dụng”, website không được trừ thêm lần nữa. Bảng mô tả dữ liệu phải nói rõ trường nguồn là số gốc hay số đã tính, cùng những điều kiện đã áp dụng.
Cần chuẩn hóa SKU và đơn vị tính trước khi nối dữ liệu. Một mã bán theo thùng không thể trừ trực tiếp vào số tồn theo chiếc khi chưa có quy đổi được kiểm soát. Sản phẩm có màu, kích thước hoặc cấu hình phải được tính theo đúng biến thể; tồn của mẫu màu xanh không bảo đảm giao được mẫu màu đen.
Với nhiều kho, tổng tồn toàn công ty có thể lớn nhưng kho phục vụ đơn lại thiếu. Quy tắc hiển thị nên xét nơi được phép xuất và khả năng điều chuyển. Đừng cộng tất cả kho rồi hứa giao ngay nếu doanh nghiệp chưa xác nhận được thời gian đưa hàng về điểm xuất.
Khi thiết kế luồng kết nối website với ERP, hãy chỉ định một nơi chịu trách nhiệm quyết định lượng được bán. Các hệ thống còn lại đọc hoặc gửi yêu cầu thay đổi theo hợp đồng dữ liệu; nhiều nơi cùng ghi đè số tồn sẽ khiến sai lệch khó truy nguyên.
Giữ hàng và trả lại tồn cần có vòng đời rõ
Đưa sản phẩm vào giỏ, gửi yêu cầu đặt hàng và được xác nhận đơn là những mốc khác nhau. Doanh nghiệp phải chọn mốc nào bắt đầu giữ hàng. Giữ ngay khi thêm vào giỏ có thể khóa lượng bán vì giỏ bị bỏ quên; chỉ giữ quá muộn lại làm nhiều người cùng mua phần hàng cuối.
Không có một mốc phù hợp cho mọi mô hình. Đơn B2B cần duyệt điều kiện bán có thể nhận dưới dạng yêu cầu trước, còn luồng thanh toán trực tuyến có thể cần giữ tạm với thời hạn rõ. Quan trọng là màn hình giải thích đúng cam kết ở từng bước và hệ thống có thể giải phóng giữ chỗ khi hết hạn.
Khi đơn được xuất kho, cần chuyển trạng thái lượng đã giữ sang nghiệp vụ xuất tương ứng, tránh trừ thêm vào lượng khả dụng đã giảm từ trước. Khi đơn hủy trước xuất, chỉ giải phóng phần thực sự còn giữ. Hàng khách trả về phải qua bước nhận và kiểm tra phù hợp trước khi được bán lại.
Nếu hai khách cùng mua sản phẩm cuối, thao tác kiểm tra và giữ lượng bán phải được kiểm soát tại hệ thống quyết định tồn. Kiểm tra trên màn hình rồi vài giây sau mới trừ là khoảng hở có thể dẫn đến cùng chấp nhận hai đơn. Đội kỹ thuật cần chứng minh cách xử lý yêu cầu đồng thời trong bài kiểm thử.
Khi phát hiện số giữa hai nơi không khớp, quy trình đối soát dữ liệu website với ERP cần lần theo mã giao dịch giữ, xuất và giải phóng. Sửa tay con số cuối cùng có thể làm màn hình đẹp lại nhưng vẫn để nguyên lỗi nghiệp vụ gây lệch lần sau.
Hiển thị thế nào khi dữ liệu chưa chắc chắn?
Không phải website nào cũng cần công khai số lượng chính xác. Khách lẻ có thể chỉ cần “có thể đặt”, “chờ xác nhận” hoặc “tạm hết”; khách đại lý có thể cần lượng đặt tối đa theo tài khoản. Hãy chọn mức chi tiết phục vụ quyết định mua mà doanh nghiệp đủ khả năng cập nhật.
Với dữ liệu cập nhật theo lịch, nên ghi thời điểm cập nhật và kiểm tra lại tại bước chốt đơn. Nhãn “còn hàng” trên trang sản phẩm chỉ là thông tin tại thời điểm đọc, không thay thế quyết định giữ hàng. Nếu dữ liệu quá cũ so với ngưỡng doanh nghiệp đã chọn, chuyển sang xác nhận thủ công hoặc tạm ngừng nhận đơn cho mặt hàng đó.
Ngưỡng dữ liệu cũ cần dựa trên tốc độ bán và mức độ quan trọng của việc giao đúng, không chọn tùy tiện cho tất cả sản phẩm. Hàng bán nhanh, số lượng ít cần kiểm soát chặt hơn hàng chỉ dùng để nhận yêu cầu báo giá. Đừng đưa một con số phút chung thành lời bảo đảm cho mọi nhóm hàng.
Trong một website phục vụ nhà phân phối và đại lý, lượng được phép mua còn có thể phụ thuộc hạn mức hoặc phần hàng phân bổ theo kênh. Hãy thể hiện rõ “số có thể đặt cho tài khoản này” nếu đó là con số đang hiển thị, tránh khiến đại lý hiểu nhầm thành toàn bộ tồn công ty.
Thông báo khi không đủ hàng nên giữ lại thông tin khách đã nhập và nêu lựa chọn tiếp theo: giảm số lượng, chờ xác nhận hoặc bỏ mặt hàng. Không tự đổi sang sản phẩm khác hay ngày giao khác mà chưa cho khách xác nhận. Trải nghiệm xử lý thiếu hàng quan trọng không kém nhãn còn hàng ban đầu.
Kiểm thử bán vượt tồn trước khi mở luồng
Hãy chọn một nhóm SKU nhỏ, có người phụ trách kho và bán hàng cùng kiểm tra. Lập bảng tồn đầu, thao tác phát sinh và tồn kỳ vọng sau mỗi bước. Đội nghiệm thu cần xem cả website lẫn dữ liệu nguồn; màn hình đúng một lần chưa đủ chứng minh quy trình đúng.
Các tình huống dưới đây giúp bộc lộ những lỗi mà thử một đơn bình thường thường không phát hiện. Mỗi lần thử phải ghi mã giao dịch để có thể đối chiếu, không chỉ chụp lại số lượng cuối cùng.
- Hai yêu cầu đồng thời tranh cùng lượng hàng cuối.
- Khách tăng, giảm số lượng sau khi đã giữ hàng.
- Đơn hết thời hạn giữ hoặc hủy một phần trước xuất.
- Yêu cầu đồng bộ được gửi lại sau lỗi kết nối.
- Hàng trả về chưa kiểm tra và kho nguồn tạm không phản hồi.
Chỉ mở rộng sau khi người vận hành giải thích được từng biến động và có cách dừng nhận đơn khi dữ liệu không đáng tin. Theo dõi đơn phải giảm số lượng do thiếu hàng, lượng giữ quá hạn và chênh lệch cần sửa tay. Những dấu hiệu này cho biết quy tắc nào còn cần điều chỉnh.
Tồn kho khả dụng đáng tin giúp website nhận đơn trong phạm vi doanh nghiệp thực sự đáp ứng. WebsiteHanoi có thể cùng đội kho và bán hàng rà soát một luồng giữ hàng trước, rồi mới mở rộng đồng bộ cho toàn bộ danh mục.
