Điều chỉnh tồn kho có phê duyệt trong OMS + WMS: sửa lệch tồn mà không mất kiểm soát

Tóm tắt nhanh

Điều chỉnh tồn kho có phê duyệt là quy trình cho phép doanh nghiệp sửa chênh lệch tồn nhưng không để nhân viên tự thay số lượng tùy ý. OMS cần biết điều chỉnh đó ảnh hưởng đến tồn khả dụng, đơn đang giữ tồn, đơn hủy, đơn thiếu hàng và đồng bộ lên marketplace như thế nào; WMS cần ghi nhận SKU, barcode, bin location, trạng thái hàng, người kiểm, lý do và bằng chứng thao tác. Với doanh nghiệp ecommerce Việt Nam, quy trình này giúp giảm overselling, giảm tranh cãi giữa kho và CSKH, phân biệt lỗi dữ liệu với lỗi vận hành và giữ báo cáo tồn kho đủ tin cậy sau mùa sale.

• Từ khóa trọng tâm: điều chỉnh tồn kho có phê duyệt, stock adjustment OMS WMS, sửa lệch tồn kho ecommerce, phân quyền điều chỉnh tồn.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp cần kiểm soát đơn đa kênh, tồn khả dụng, SKU, barcode, vị trí kho, PDA, kiểm kê, điều chỉnh tồn và báo cáo vận hành.
• Bối cảnh Việt Nam: đơn từ Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website, Facebook và Zalo thường có COD, đơn hủy nhanh, hàng hoàn, combo, thiếu hàng và nhiều ca kho.
• Quy trình kho liên quan: cycle count, scan barcode, kiểm vị trí, khóa tồn, chuyển trạng thái hàng, đề xuất điều chỉnh, phê duyệt, cập nhật tồn khả dụng và đồng bộ lại với OMS.

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

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

Vì sao không nên cho sửa tồn trực tiếp?

Sửa tồn trực tiếp có vẻ nhanh, nhưng nó làm mất câu hỏi quan trọng nhất: vì sao tồn bị lệch. Nếu một SKU đang báo còn 20 nhưng kiểm vị trí chỉ thấy 12, nguyên nhân có thể là picking quên scan, hàng nằm sai kệ, nhập thiếu, hàng hoàn chưa phân loại, thất lạc trong packing hoặc đơn hủy chưa trả tồn. Nếu nhân viên chỉ sửa 20 thành 12, doanh nghiệp mất cơ hội xử lý nguyên nhân gốc.

Trong ecommerce đa kênh, một lần sửa tồn còn ảnh hưởng đến đơn đang bán. OMS có thể đã giữ tồn cho đơn Shopee, Lazada hoặc TikTok Shop; nếu WMS giảm tồn mà không kiểm đơn đang giữ, hệ thống có thể tạo thêm đơn thiếu hàng. Ngược lại, nếu cộng tồn sai, marketplace sẽ tiếp tục nhận đơn cho hàng không thật sự bán được.

• Sửa số lượng không đủ; cần ghi nguyên nhân, vị trí và trạng thái hàng.
• Tồn khả dụng phải được tính lại sau khi trừ tồn giữ, hàng lỗi, hàng hoàn chờ kiểm và tồn khóa.
• Mọi điều chỉnh nên có log để truy vết theo người thao tác, thời gian và SKU.

Tách rõ đề xuất điều chỉnh và phê duyệt

Một quy trình tốt nên tách người phát hiện lệch tồn khỏi người duyệt điều chỉnh. Nhân viên kho có thể tạo đề xuất khi PDA scan vị trí A-01-03 nhưng số lượng thực tế không khớp. Đề xuất cần ghi SKU, barcode, vị trí, số lượng hệ thống, số lượng thực tế, lý do ban đầu và bằng chứng như ảnh kệ, ảnh kiện hoặc biên bản kiểm kê.

Quản lý kho hoặc người được phân quyền sẽ kiểm tra trước khi duyệt. Với chênh lệch nhỏ do kiểm kê thường kỳ, quy trình có thể duyệt nhanh. Với chênh lệch lớn, hàng giá trị cao, hàng COD đang tranh chấp hoặc SKU đang chạy campaign, hệ thống nên yêu cầu kiểm tra lại vị trí khác, đơn đang giữ tồn, hàng hoàn và log picking gần nhất.

• Nhân viên kho được tạo đề xuất nhưng không tự sửa tồn khả dụng.
• Quản lý duyệt theo ngưỡng số lượng, giá trị hàng hoặc nhóm SKU rủi ro.
• Kế toán hoặc chủ doanh nghiệp có thể cần xem điều chỉnh ảnh hưởng giá vốn và báo cáo.

Lý do điều chỉnh phải đủ chi tiết để cải tiến quy trình

Nếu mọi chênh lệch đều được ghi là “kiểm kê lệch”, báo cáo không giúp cải tiến gì. Doanh nghiệp nên chuẩn hóa reason code theo nhóm nguyên nhân: sai tồn đầu kỳ, nhập thiếu, nhập thừa, picking thiếu scan, cất sai vị trí, hàng hỏng, hàng mất barcode, hàng hoàn nhập sai trạng thái, đơn hủy chưa trả tồn, hàng thất lạc tại packing hoặc chênh lệch từ kho 3PL.

Khi lý do đủ rõ, quản lý có thể thấy lỗi lặp lại ở đâu. Nếu nhiều điều chỉnh đến từ hàng hoàn, cần sửa quy trình nhận hàng hoàn. Nếu lệch nhiều ở fast-pick, cần xem replenishment và scan vị trí. Nếu lệch ở SKU livestream, cần kiểm lại mapping combo, quà tặng và tốc độ giữ tồn sau phiên live.

• Tạo danh mục lý do theo nhập hàng, xuất hàng, hàng hoàn, kiểm kê, mất/hỏng và dữ liệu.
• Không cho chọn lý do chung chung nếu giá trị điều chỉnh vượt ngưỡng.
• Báo cáo lý do điều chỉnh theo SKU, kho, vị trí, ca làm và nhân viên.

PDA và barcode giúp điều chỉnh tồn dựa trên bằng chứng

Điều chỉnh tồn không nên bắt đầu từ màn hình nhập số. Nó nên bắt đầu từ thao tác kiểm vật lý. Nhân viên dùng PDA scan vị trí, scan barcode SKU, nhập số đếm thực tế và nếu cần chụp ảnh. Nếu SKU được tìm thấy ở vị trí khác, hệ thống nên tạo nhiệm vụ chuyển vị trí thay vì giảm tồn. Nếu barcode không khớp, cần đưa vào ngoại lệ để kiểm dữ liệu SKU.

Với hàng có serial/IMEI, batch hoặc hạn sử dụng, điều chỉnh càng cần chặt hơn. Không chỉ sửa số lượng tổng, WMS phải biết serial nào thiếu, lô nào thừa, hạn sử dụng nào không khớp và trạng thái tồn nào bị ảnh hưởng. Điều này đặc biệt quan trọng với mỹ phẩm, thực phẩm chức năng, điện tử, mẹ và bé hoặc hàng giá trị cao.

• Scan vị trí trước khi đếm để tránh điều chỉnh nhầm bin location.
• Scan barcode SKU để chặn nhầm màu, size, dung tích, model hoặc combo.
• Với serial, batch hoặc hạn sử dụng, điều chỉnh phải đi theo từng đơn vị truy vết.

Ảnh hưởng đến OMS, đơn đang giữ tồn và marketplace

Một điều chỉnh trong WMS không đứng riêng lẻ. Nếu giảm tồn khả dụng, OMS cần biết đơn nào đang giữ SKU đó, đơn nào sắp picking và kênh nào đang hiển thị tồn bán được. Nếu cộng tồn, OMS cần kiểm trạng thái hàng có thật sự được phép bán hay chỉ đang chờ QC. Đây là lý do điều chỉnh tồn phải nối với trạng thái tồn, không chỉ nối với số lượng.

Ví dụ, kho phát hiện thiếu 10 sản phẩm tại vị trí fast-pick. Nếu bulk storage còn hàng, hệ thống nên tạo nhiệm vụ replenishment thay vì báo thiếu cho tất cả đơn. Nếu toàn kho thật sự thiếu, OMS cần xác định đơn nào sẽ bị ảnh hưởng, ưu tiên theo SLA, trạng thái thanh toán, COD, kênh bán và chính sách hủy một phần. Khi có dữ liệu rõ, CSKH không phải hỏi kho qua chat nhóm.

• Kiểm tra đơn đang giữ tồn trước khi duyệt giảm tồn.
• Chỉ đồng bộ lên sàn phần tồn đã đạt trạng thái bán được.
• Tự động cảnh báo nếu điều chỉnh làm SKU rơi xuống dưới tồn an toàn.

Kiểm soát điều chỉnh sau đơn hủy, hàng hoàn và thiếu hàng

Ba nguồn lệch tồn phổ biến là đơn hủy, hàng hoàn và thiếu hàng tại checking. Đơn hủy trước picking có thể trả tồn ngay. Đơn hủy sau picking hoặc sau packing cần kiểm hàng đã quay lại đúng vị trí chưa. Hàng hoàn cần qua khu chờ kiểm trước khi nhập lại bán được. Thiếu hàng tại checking cần phân biệt thiếu thật, lấy nhầm, sai vị trí hay combo thiếu thành phần.

Nếu các tình huống này đều được xử lý bằng điều chỉnh tồn thủ công, báo cáo sẽ rối. JSTERP OMS + WMS nên có trạng thái riêng cho từng luồng: trả tồn do hủy, nhập hàng hoàn, báo thiếu SKU, chuyển hàng lỗi, khóa tồn kiểm kê và điều chỉnh tồn sau phê duyệt. Khi trạng thái rõ, doanh nghiệp ít phải sửa số lượng trực tiếp hơn.

• Đơn hủy sau packing phải kiểm hàng vật lý trước khi trả tồn bán được.
• Hàng hoàn không tự động cộng vào tồn khả dụng nếu chưa QC.
• Thiếu hàng tại checking nên tạo ngoại lệ và cycle count vị trí liên quan.

Checklist go-live cho quy trình điều chỉnh tồn

Trước khi go-live, doanh nghiệp nên chạy thử bằng các tình huống thật: kiểm kê lệch một SKU bán chạy, phát hiện hàng nằm sai vị trí, đơn hủy sau packing, hàng hoàn thiếu phụ kiện, SKU mất barcode, serial thiếu, lô hàng nhập thừa và kho 3PL gửi tồn cập nhật trễ. Mỗi tình huống phải cho thấy ai tạo đề xuất, ai duyệt, tồn khả dụng thay đổi thế nào và OMS có cảnh báo đơn bị ảnh hưởng hay không.

Không nên nghiệm thu bằng việc “sửa được số tồn”. Mục tiêu đúng là sửa tồn có kiểm soát: dữ liệu sau sửa đáng tin hơn trước, nguyên nhân được ghi nhận, quyền thao tác rõ và báo cáo giúp giảm lỗi lặp lại.

• Thiết lập reason code và ngưỡng phê duyệt theo số lượng hoặc giá trị.
• Kiểm thử PDA scan vị trí, barcode, ảnh bằng chứng và log thao tác.
• Đo số lần điều chỉnh tồn thủ công trong 2 tuần đầu sau go-live.

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ủ đề Điều chỉnh tồn kho có phê duyệt 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 sửa lệch tồn theo SKU, barcode, vị trí kho, trạng thái tồn, lý do kiểm kê, đơn hủy, hàng hoàn, thiếu hàng và quyền phê duyệt mà không phá vỡ dữ liệu tồn khả dụng, 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 Điều chỉnh tồn kho có phê duyệt 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ê các lý do lệch tồn trong 30 ngày gần nhất: kiểm kê, hàng hoàn, đơn hủy, thiếu hàng, nhập sai, cất sai vị trí, kho 3PL cập nhật trễ.
• Chuẩn hóa SKU, barcode, bin location, trạng thái tồn và quyền người dùng trước khi bật phê duyệt.
• Xác định ai được tạo đề xuất, ai được duyệt, ai được xem báo cáo và ngưỡng nào cần duyệt cấp cao hơn.
• Chuẩn bị đơn thật để test: đơn COD hủy sau packing, đơn thiếu hàng tại checking, hàng hoàn thiếu phụ kiện và SKU mất barcode.
• Định nghĩa chỉ số nghiệm thu: số điều chỉnh tồn, giá trị điều chỉnh, nguyên nhân lặp lại, thời gian duyệt và tác động đến đơn đang giữ tồn.

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

JSTERP hỗ trợ doanh nghiệp thiết kế điều chỉnh tồn kho có phê duyệt bằng cách nối OMS và WMS trong cùng một luồng. WMS ghi nhận bằng chứng vật lý tại kho; OMS kiểm tra tác động đến đơn hàng, tồn khả dụng và đồng bộ marketplace.

Đội triển khai JST ERP Việt Nam có thể khảo sát hiện trạng SKU, barcode, vị trí kho, quy trình kiểm kê, hàng hoàn, đơn hủy, thiếu hàng và phân quyền nội bộ. Từ đó doanh nghiệp có thể bắt đầu bằng nhóm SKU rủi ro cao hoặc một kho trọng điểm trước khi mở rộng toàn hệ thống.

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.