Độ chính xác tồn kho ecommerce: công thức, ngưỡng và cycle count bằng OMS + WMS

Kết luận nhanh: 98% chưa nói được kho có bán đúng hàng hay không

Nếu dashboard báo độ chính xác tồn kho 98%, câu hỏi tiếp theo phải là “98% của cái gì?”. Nếu lấy tổng số đơn vị đúng chia tổng đơn vị, 9.800 sản phẩm giá thấp có thể che 200 sản phẩm bestseller bị sai. Nếu chỉ so tồn theo SKU, hàng nằm sai bin vẫn được coi là đúng dù picker không tìm thấy trước cut-off. Nếu không tách trạng thái, hàng hoàn đang chờ QC hoặc hàng đã khóa claim có thể bị phát bán. Vì vậy buyer không nên chọn phần mềm chỉ vì màn hình có chữ “tồn kho thời gian thực”; phải kiểm cách hệ thống hình thành và bảo vệ con số đó.

Quyết định thực tế gồm bốn bước. Một, định nghĩa on-hand, reserved, sellable và ATP cho toàn bộ kênh. Hai, ghi nhận từng chuyển động vật lý tại receiving, putaway, picking, checking, packing, return và transfer bằng barcode/PDA hoặc control tương đương. Ba, cycle count theo rủi ro thay vì đếm mọi SKU cùng tần suất. Bốn, khi lệch phải bảo vệ kênh bán, recount độc lập, tìm event thiếu rồi mới duyệt adjustment. Đếm chỉ tạo tín hiệu; kỷ luật giao dịch và CAPA mới giữ tồn đúng lâu dài.

Tóm tắt nhanh

• Đừng dùng một tỷ lệ tổng: đo riêng quantity, location và status accuracy.
• Đừng đếm mọi SKU như nhau: ưu tiên SKU A, giá trị cao, tồn thấp, hàng hoàn, tồn âm và campaign.
• Đừng sửa số trước khi tìm lỗi: recount độc lập, reconcile event, reason code và CAPA.
• OMS giữ lời hứa bán, WMS giữ bằng chứng vật lý: hai lớp phải dùng chung SKU, state và timestamp.

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

So sánh nhanh theo mức độ vận hành

Khoảng trống nội dung: đối thủ có tính năng kiểm kho nhưng buyer thiếu khung quyết định

Kết quả đối chiếu cho thấy khoảng trống không nằm ở định nghĩa “kiểm kê là gì”. Các help center đã mô tả nút bấm và trạng thái. Khoảng trống là cách một trưởng vận hành biến tính năng thành hệ thống kiểm soát: chọn mẫu số, phân tầng rủi ro, tránh chênh lệch giả do giao dịch đang mở, đặt owner, bảo vệ tồn phát lên sàn và chứng minh lỗi đã không tái diễn. Bài viết này tập trung vào lớp quyết định đó, không sao chép câu chữ đối thủ.

1. Độ chính xác tồn kho là một bộ chỉ số, không phải một con số

“Tồn đúng” có ít nhất ba nghĩa. Quantity accuracy hỏi hệ thống có ghi đúng bao nhiêu đơn vị của từng SKU. Location accuracy hỏi đơn vị đó có thật sự nằm tại bin mà WMS chỉ định. Status accuracy hỏi nó có ở đúng trạng thái nghiệp vụ: bán được, đã giữ, chờ QC, hỏng, đang chuyển hay đã pick. Với ecommerce đa kênh còn có lớp thứ tư: channel promise accuracy, tức số được phát lên Shopee, Lazada, TikTok Shop và website có khớp ATP sau reservation và buffer hay không.

Không nên cộng chênh lệch có dấu. SKU A thiếu 10 và SKU B dư 10 không tạo ra kho “đúng 100%”; đó là hai lỗi có thể gây hủy đơn, thất thoát hoặc sai mua hàng. Hãy dùng giá trị tuyệt đối theo từng SKU-bin-status, đồng thời giữ cả hai góc nhìn: tỷ lệ dòng đúng tuyệt đối và độ lớn chênh lệch theo đơn vị hoặc giá vốn.

2. Công thức minh họa và cách đọc để không bị tỷ lệ đẹp đánh lừa

SKU line accuracy = số dòng SKU có thực tế bằng hệ thống / tổng dòng SKU đã đếm × 100%

Unit accuracy = [1 − tổng trị tuyệt đối (thực tế − hệ thống) / tổng đơn vị hệ thống] × 100%

Location accuracy = số đơn vị ở đúng bin / tổng đơn vị đã kiểm vị trí × 100%

Ví dụ một phạm vi có 100 SKU và 10.000 đơn vị. Mười SKU lệch mỗi SKU một đơn vị, còn 90 SKU đúng. SKU line accuracy là 90%, trong khi unit accuracy là 99,9%. Cả hai đều đúng về toán nhưng trả lời hai câu khác nhau. Nếu mười SKU lệch đều là hàng bán nhanh chỉ còn một-hai đơn vị, rủi ro overselling rất cao dù unit accuracy trông xuất sắc. Ngược lại, một SKU C có 1.000 đơn vị lệch 10 có thể làm unit accuracy giảm nhưng ít tác động tức thời đến SLA. Dashboard phải cho phép drill-down thay vì dùng một con số để xếp hạng nhân viên.

Trường hợp hệ thống bằng 0 cần quy tắc riêng vì công thức có thể không xác định hoặc bỏ qua phantom inventory. Hãy báo cáo “zero-bin exception”: hệ thống bằng 0 nhưng đếm thấy hàng, và “empty-bin exception”: hệ thống còn hàng nhưng bin trống. Hai tín hiệu này thường quan trọng hơn trung bình toàn kho vì liên quan trực tiếp đến mất doanh thu, bổ sung hàng sai và thời gian tìm kiếm.

3. Chuẩn hóa tám trạng thái trước khi nói về đồng bộ tồn kho

ATP minh họa = sellable on-hand − reservation hợp lệ − safety stock − channel buffer − blocked allocation

Công thức chính xác phụ thuộc mô hình, nhưng phải có một owner và một tài liệu được duyệt. Không được để Shopee lấy on-hand, website lấy sellable còn TikTok Shop lấy một file Excel khác. Khi đơn mới về, OMS phải tạo reservation nguyên tử trước khi phát lệnh kho; khi WMS pick, trạng thái chuyển có event; khi hủy, hàng chỉ quay lại sellable sau bước vật lý phù hợp. Nếu một hệ thống chỉ “đồng bộ số” mà không hiểu vòng đời, nó có thể đồng bộ sai rất nhanh.

4. Chọn tần suất cycle count theo rủi ro, không theo thói quen

ABC theo doanh thu hoặc số lượng bán là điểm bắt đầu, chưa phải kết luận. Hãy cộng thêm giá vốn, độ giống nhau giữa biến thể, số lần di chuyển, lịch sử short pick, return rate, số bin, serial/lot, hạn dùng và campaign. Một SKU C ít bán nhưng giá trị cao hoặc dễ mất vẫn cần tần suất chặt. Một SKU A có barcode rõ và location cố định có thể ổn định hơn SKU B thường xuyên đổi kệ.

Đây là lịch khởi điểm, không phải chuẩn ngành bắt buộc. Sau mỗi chu kỳ, tính số chênh lệch trên 100 dòng đã đếm, giá trị variance, thời gian tìm nguyên nhân và tỷ lệ lỗi lặp. Nếu ba chu kỳ liên tiếp ổn định, có thể giãn lịch; nếu lỗi tăng, campaign sắp đến hoặc quy trình vừa đổi, tăng tần suất. Mục tiêu là kiểm đúng nơi rủi ro xuất hiện, không tạo công việc đếm để báo cáo đủ số lượt.

5. Quy trình cycle count 12 bước không làm gián đoạn toàn kho

1. Chọn phạm vi: SKU-bin-status theo lịch ABC hoặc trigger rủi ro; ghi rõ lý do và owner.
2. Kiểm giao dịch mở: receiving, putaway, wave, picking, staging, return và transfer chưa đóng.
3. Tạo snapshot: lưu số hệ thống và timestamp; không dùng báo cáo thay đổi trong lúc đếm làm baseline.
4. Khoanh vùng: khóa bin, SKU hoặc dùng count-in-motion có quy tắc ghi mọi movement sau snapshot.
5. Blind count: người đếm không nhìn số kỳ vọng để tránh “đếm về đúng con số”.
6. Quét vị trí và hàng: scan bin, SKU/barcode, lot/serial và trạng thái; ghi hàng không nhãn riêng.
7. Gửi count lần một: hệ thống tính variance nhưng chưa adjustment tự động.
8. Recount độc lập: người khác kiểm lại chênh lệch vượt ngưỡng số lượng, giá trị hoặc rủi ro.
9. Mở rộng tìm kiếm: kiểm bin lân cận, staging, return/QC, damaged, receiving và kiện đã pack.
10. Reconcile event: nối variance với receipt, move, pick, cancel, return, transfer hoặc sync log.
11. Duyệt adjustment: reason code, evidence, người đề nghị, người duyệt và ảnh hưởng ATP.
12. Đóng CAPA: sửa quy trình, mapping, đào tạo hoặc hệ thống; kiểm lại sau thời hạn đã đặt.

Nếu kho không thể khóa cả SKU vì vẫn phải xuất đơn, có thể khóa từng bin trong cửa sổ ngắn hoặc tạo snapshot rồi cộng trừ toàn bộ movement có timestamp sau snapshot. Điều kiện là event phải đầy đủ và thứ tự đáng tin cậy. Nếu kho đang xử lý bằng giấy, chat và nhiều file rời, count-in-motion dễ tạo chênh lệch giả; nên chọn cửa sổ yên tĩnh và phạm vi nhỏ trước.

6. False discrepancy: sáu tình huống đếm đúng nhưng so sai

• Hàng đã receiving trên hệ thống nhưng xe chưa dỡ hoặc chưa blind count xong.
• Picker đã lấy hàng khỏi bin nhưng task chưa confirm, hoặc đã confirm nhưng hàng còn trên xe đẩy.
• Đơn hủy đã release reservation nhưng hàng vật lý chưa reverse putaway về bin.
• Kiện hoàn carrier giao tại cửa nhưng return receiving chưa scan, hoặc đã scan kiện nhưng chưa QC item.
• Transfer đã cộng ở kho nhận trước khi kho gửi bàn giao và chứng từ in-transit chưa khép kín.
• Đơn vị tính sai: hệ thống ghi một carton, người đếm ghi từng piece, combo bị tách hoặc barcode mapping sang SKU khác.

Do đó count sheet cần lưu snapshot, cut-off event và trạng thái hàng đang mở. Đừng dùng adjustment để “xóa” một giao dịch chưa hoàn tất; khi event thật đến sau đó, tồn sẽ lệch lần nữa theo hướng ngược lại. Cách xử lý là treo exception, xác định transaction owner và đóng luồng gốc trước khi điều chỉnh số cuối cùng.

7. Root cause map từ cửa nhận hàng đến hàng hoàn

Pareto nguyên nhân nên dựa trên event và evidence, không dựa vào cảm giác “nhân viên bất cẩn”. Nếu 60% chênh lệch xuất hiện sau hủy đơn đã pick, sửa quy trình reverse putaway có thể hiệu quả hơn tăng số lượt cycle count. Nếu lệch tập trung ở một nhóm barcode nhà cung cấp dùng chung cho biến thể, cần sửa SKU master và mapping. Nếu số hệ thống tự tăng sau retry, cần kiểm idempotency và integration log. Mỗi lỗi phải có process owner khác nhau.

8. Ngưỡng hành động: thiết kế theo tác động thay vì dùng “tùy tình hình”

Doanh nghiệp có thể bắt đầu bằng ma trận ba cấp rồi hiệu chỉnh. Cấp đỏ: tồn âm, SKU A không tìm thấy, serial giá trị cao lệch, hàng recall lẫn sellable, hoặc chênh lệch có thể làm oversell trong ngày; tạm giảm ATP/buffer, mở recount ngay và chỉ định incident owner. Cấp vàng: chênh lệch nhỏ không ảnh hưởng đơn mở nhưng lặp lại; giữ theo dõi, recount trong ca và tạo CAPA. Cấp xanh: sai khác do rounding, UoM hoặc event đang mở đã được chứng minh; đóng sau reconcile, không tạo adjustment giả.

Ngưỡng số lượng và giá trị phải do operations cùng finance duyệt. Ví dụ minh họa: mọi serial lệch đều đỏ; SKU A lệch ít nhất một đơn vị là vàng hoặc đỏ tùy ATP; SKU C chỉ escalated khi vượt số lượng hay giá trị nhất định. Nhưng một ngưỡng tiền không được che rủi ro khách hàng. Một phụ kiện giá vốn thấp bị thiếu có thể làm cả đơn bundle bị hủy và mất SLA cao hơn nhiều so với giá vốn phụ kiện.

9. OMS-only hay OMS + WMS cho bài toán độ chính xác tồn?

OMS-only phù hợp khi doanh nghiệp chủ yếu cần gom đơn, mapping SKU theo kênh, reservation và phát ATP; kho nhỏ, ít vị trí, một người có thể nhìn thấy toàn bộ hàng và biến động vật lý thấp. Trong bối cảnh này, cycle count theo SKU và một location mặc định có thể đủ. Điều kiện vẫn là đơn từ mọi kênh đi qua cùng nguồn giữ tồn và hủy đơn không release sai thời điểm.

OMS + WMS nên được đánh giá khi “hệ thống còn hàng nhưng picker không tìm thấy”, nhiều bin/kho/3PL, có PDA, replenishment, wave picking, staging, combo, lot/serial, hàng hoàn, QC hoặc nhiều ca. OMS trả lời nên hứa bán bao nhiêu và đơn nào được ưu tiên; WMS trả lời hàng nào đang ở đâu, ai đã di chuyển và bằng chứng vật lý là gì. Chỉ OMS không tự tạo location accuracy; chỉ WMS không tự giải quyết reservation đa kênh. Hai lớp cần chung ID SKU, order, parcel, location, state và event timestamp.

Xem thêm sản phẩm OMS + WMS, giải pháp marketplace đa kênh và giải pháp vận hành kho để đối chiếu phạm vi phù hợp.

10. Tồn đa sàn: source of truth, reservation và buffer

Mỗi marketplace có trạng thái đơn, độ trễ và cơ chế retry riêng. Vì vậy không nên để từng sàn tự sở hữu một phần tồn bằng file cập nhật thủ công nếu cùng bán một pool hàng. OMS cần nhận đơn, kiểm idempotency, tạo reservation và phát lại ATP. Khi kênh mất kết nối, chính sách phải rõ: giữ buffer, giảm tồn phát, dừng một SKU hay chấp nhận queue. Không được âm thầm dùng số cũ rồi gọi đó là real-time.

Buffer không chữa được dữ liệu gốc sai. Nó chỉ hấp thụ độ trễ và biến động trong một giới hạn. Đặt buffer quá cao làm mất cơ hội bán; quá thấp gây oversell. Hãy tính theo tốc độ bán trong cửa sổ đồng bộ, percentile spike, thời gian retry và độ chính xác vật lý của SKU. SKU A trong livestream cần rule khác SKU C ít bán. Sau mỗi campaign, so đơn hủy do hết hàng, số reservation orphan và latency distribution để hiệu chỉnh.

Đọc thêm hướng dẫn đồng bộ tồn kho Shopee, Lazada và TikTok Shop, bài tồn khả dụng và tồn chiếm dụngvà cách tránh overselling khi bán nhiều sàn.

11. Hàng hoàn là vùng mù lớn nhất của inventory accuracy

“Carrier đã giao hoàn” chỉ chứng minh một kiện đến điểm nhận, không chứng minh đúng SKU, đủ số lượng, đúng serial hay đủ điều kiện bán lại. Quy trình cần tách return receiving khỏi return-to-stock. Người nhận scan mã vận đơn, chụp tình trạng seal, cân nếu cần và đưa kiện vào bin chờ QC. QC mở kiện, kiểm SKU, barcode, serial, phụ kiện, bao bì, dấu hiệu sử dụng và phân hạng A/B/C, rework, damaged hoặc claim. Chỉ disposition A đạt rule mới chuyển vào sellable bin.

Nếu cộng hàng hoàn vào sellable ngay khi carrier cập nhật trạng thái, kho tạo phantom inventory: kênh bán hứa một món chưa về, về sai hoặc hỏng. Nếu hàng đã QC nhưng nằm nhiều ngày ở khu return, hệ thống có thể đúng status nhưng sai location và làm mất cơ hội bán. Dashboard cần return aging theo các mốc carrier delivered → warehouse received → QC started → disposition → putaway, cùng owner cho mỗi khoảng trễ.

12. Kho nội bộ và 3PL: cùng công thức, khác quyền kiểm chứng

Khi dùng 3PL, “inventory accuracy 99,x%” trong hợp đồng phải có định nghĩa: theo unit hay SKU line, gross hay net, theo toàn kho hay sample, có tách location/status không, cửa sổ claim bao lâu và ai chịu variance sau count. Doanh nghiệp cần quyền nhận inventory snapshot, transaction ledger, ASN discrepancy, outbound/return evidence, cycle-count result và adjustment reason. Một tỷ lệ SLA không có mẫu số và dữ liệu drill-down khó dùng để đối soát.

Thiết lập control total tại mỗi lần inbound/transfer, pilot SKU đại diện và recount khi variance vượt ngưỡng. OMS vẫn phải giữ inventory ownership logic: 3PL WMS báo on-hand và event, OMS tính phần được phân cho kênh theo hợp đồng và buffer. Với mô hình hybrid, hàng in-transit không được xuất hiện ở cả kho gửi và kho nhận. Xem khung quyết định kho tự vận hành, 3PL hay hybrid.

13. RACI: ai đếm, ai duyệt, ai bảo vệ kênh bán?

Tách người đếm và người duyệt đặc biệt quan trọng với SKU giá trị cao. System admin không nên tự sửa tồn chỉ vì ops nhắn chat; cần ticket hoặc exception record. Ecommerce ops có quyền giảm ATP khẩn cấp để bảo vệ khách nhưng không tự quyết định nguyên nhân vật lý. Warehouse owner chịu trách nhiệm đóng movement, còn finance tham gia khi adjustment vượt ngưỡng giá trị hoặc liên quan claim. RACI làm rõ lỗi thuộc process nào thay vì đẩy mọi việc cho “nhân viên kiểm kho”.

14. Dashboard cần dẫn tới hành động, không chỉ hiển thị accuracy

• Quantity, location và status accuracy theo kho, zone, bin, SKU class, ca và process owner.
• Variance unit và value; không net dư với thiếu; drill-down tới count và event liên quan.
• Top reason code: receiving, putaway, short pick, cancel reversal, return QC, transfer, sync, UoM, manual adjustment.
• Empty-bin, zero-bin, negative inventory, orphan reservation và SKU phát bán lớn hơn ATP.
• Count plan completion, recount rate, false-discrepancy rate và thời gian từ phát hiện đến đóng CAPA.
• Tác động khách hàng: oversell, hủy do hết hàng, order line short, lỡ cut-off và thời gian picker tìm hàng.

Dashboard theo người dễ tạo hành vi che lỗi hoặc “đếm về đúng”. Giai đoạn đầu nên ưu tiên process và location. Nếu một zone có variance cao, kiểm layout, replenishment, label, ánh sáng, độ giống SKU và đường di chuyển. Khi dùng chỉ số cá nhân, phải đặt trong bối cảnh volume, difficulty và exception để không thưởng cho việc né SKU khó.

15. Sai lầm phổ biến cần sửa

Sai lầm 1: “98% là chuẩn tốt cho mọi doanh nghiệp”

Một ngưỡng tổng không phản ánh mix SKU và rủi ro. Hãy đặt target theo class, đồng thời theo dõi location, status và customer impact.

Sai lầm 2: kiểm kê cuối năm là đủ

Kiểm kê toàn phần cung cấp snapshot, nhưng lỗi phát sinh hôm sau vẫn tiếp tục. Cycle count và event control giúp phát hiện sớm mà không đóng toàn kho.

Sai lầm 3: thấy lệch thì sửa tồn ngay

Adjustment không có root cause chỉ làm dashboard đẹp. Recount, kiểm giao dịch mở, reason code, evidence và CAPA phải đi cùng.

Sai lầm 4: barcode tự động tạo ra accuracy

Barcode sai mapping, scan sai điểm hoặc cho phép bypass vẫn tạo dữ liệu sai có vẻ đáng tin. Thiết kế scan gate và quyền ngoại lệ quan trọng hơn mua thiết bị.

Sai lầm 5: tồn đồng bộ nghĩa là tồn vật lý đúng

API có thể truyền chính xác một con số sai. Đồng bộ phải bắt đầu từ transaction discipline trong kho và định nghĩa ATP.

Sai lầm 6: hàng hoàn về là cộng tồn

Phải qua receiving, QC, disposition và putaway. Trạng thái carrier không thay thế bằng chứng item.

Sai lầm 7: đếm nhiều hơn luôn tốt hơn

Đếm lặp nhưng không sửa receiving, cancel hoặc return tạo chi phí và tiếp tục lệch. Hãy tối ưu theo Pareto nguyên nhân.

16. Ví dụ vận hành minh họa cho kho 2.000 SKU

Giả sử một kho có 2.000 SKU, trong đó 120 SKU A tạo phần lớn order line, 480 SKU B và 1.400 SKU C. Đội không cần đếm 2.000 SKU mỗi tuần. Có thể pilot 20 SKU A/ngày, toàn bộ 120 SKU A trong một tuần; 120 SKU B/tuần để mỗi SKU B được kiểm trong tháng; SKU C chia theo quý, đồng thời thêm mọi zero-bin, negative, return spike và bin có short pick. Con số chỉ minh họa cách thiết kế tải, phải kiểm với số bin và thời gian đếm thực tế.

Tuần đầu, 100 dòng đếm có 94 dòng đúng quantity, 91 đúng location và 88 đúng status. Nếu chỉ nhìn unit accuracy 99,6%, đội có thể bỏ qua vấn đề. Drill-down cho thấy tám SKU hàng hoàn đã QC nhưng chưa putaway và ba SKU nằm sai bin do replenishment không scan. Hành động đúng là sửa return task aging và bắt buộc scan source-destination cho replenishment; không phải tăng buffer trên sàn cho mọi SKU. Sau hai tuần, lặp lại cùng sample và trigger để xác nhận CAPA có hiệu quả.

17. Kế hoạch triển khai 30 ngày

Ngày 1-5: định nghĩa và baseline

Chốt state model, source of truth, ATP, owner; xuất event, count history, oversell, return aging và adjustment. Không sửa target trước khi hiểu baseline.

Ngày 6-10: phân tầng và thiết kế count

Phân ABC+risk, chọn 20-50 SKU đại diện, viết count SOP, snapshot, freeze/movement rule, recount và approval threshold.

Ngày 11-17: pilot bằng PDA/barcode

Blind count, scan bin-SKU-state, ghi false discrepancy, thời gian đếm và evidence. Kiểm cả SKU đúng, sai bin, return và UoM.

Ngày 18-24: root cause và CAPA

Dựng Pareto theo process; sửa một-hai cơ chế lớn nhất như reverse putaway, return QC hoặc barcode mapping; đào tạo đúng vai trò.

Ngày 25-30: retest và mở rộng

Đếm lại sample, so customer impact, điều chỉnh tần suất, mở dashboard và quyết định phạm vi OMS-only hoặc OMS + WMS tiếp theo.

18. Checklist thực thi cho buyer Việt Nam

1. Chọn một source of truth cho sellable stock và viết rõ công thức ATP: on-hand đủ điều kiện trừ reservation, blocked, safety stock và các khoản giữ khác.
2. Xuất 8-12 tuần dữ liệu SKU-bin-status-event; lập Pareto theo tần suất bán, giá trị, sai lệch, short pick, return và campaign để chọn phạm vi cycle count đầu tiên.
3. Pilot blind count trên 20-50 SKU đại diện; đo quantity, location và status accuracy, thời gian đếm, false discrepancy và thời gian đóng nguyên nhân.
4. Thiết lập reason code, recount độc lập, quyền adjustment và dashboard CAPA; không cho phép “sửa cho khớp” mà thiếu chứng từ.
5. Sau 2-4 chu kỳ, điều chỉnh tần suất theo rủi ro thật và kiểm lại overselling, hủy do hết hàng, thời gian tìm hàng, return aging và độ ổn định campaign.

Khi demo nhà cung cấp, hãy yêu cầu chạy một tình huống khó: đơn đa sàn giữ cùng SKU, picker short pick, đơn hủy sau release, hàng hoàn chờ QC, cycle count phát hiện sai bin và adjustment cần duyệt. Yêu cầu xem event, timestamp, reason và người thao tác; đừng chỉ xem màn hình tổng tồn. Đồng thời hỏi cách export transaction ledger, cách retry khi mất kết nối và cách xử lý inventory snapshot với 3PL.

19. Câu hỏi nghiệm thu OMS + WMS về inventory accuracy

• SKU master và barcode có chặn trùng, sai biến thể, sai UoM và thay đổi không có lịch sử không?
• WMS có bắt buộc scan SKU + bin tại receiving, putaway, move, pick, return và count theo phạm vi không?
• OMS tạo reservation nguyên tử, chống đơn trùng và release theo acknowledgement hay chỉ sửa số định kỳ?
• Có tách sellable, reserved, QC, damaged, return, staging và in-transit; quyền chuyển trạng thái thuộc ai?
• Cycle count có blind count, snapshot, movement control, recount, threshold, reason code và approval không?
• Adjustment có audit trail và liên kết evidence; có đo lỗi lặp sau CAPA không?
• Đồng bộ sàn có monitor latency, retry, buffer, mismatch và cơ chế giảm ATP an toàn khi outage không?
• Hàng hoàn và 3PL có item-level evidence, control total, claim window và return-to-stock gate không?

20. Kết luận: dùng cycle count để sửa cơ chế, không dùng để che sai số

Kho chính xác không phải kho luôn báo 100%; đó là kho biết con số đại diện cho trạng thái nào, phát hiện sai ở đâu, bảo vệ khách hàng ra sao và đóng nguyên nhân bằng evidence. Bắt đầu từ quantity-location-status, source of truth và ATP. Sau đó cycle count theo rủi ro, recount độc lập và theo Pareto lỗi. Nếu kho nhỏ và vật lý đơn giản, OMS-only cùng quy trình chặt có thể đủ. Khi nhiều bin, PDA, ca, kho, 3PL, hàng hoàn và campaign xuất hiện, OMS + WMS giúp nối lời hứa đa kênh với bằng chứng vật lý trong kho.

Doanh nghiệp có thể xem thêm câu hỏi thường gặp, cam kết dịch vụvà hướng dẫn chọn OMS + WMS cho ecommerce Việt Nam. Nếu cần xác định baseline, ngưỡng và lộ trình theo dữ liệu thật, hãy liên hệ JST ERP Việt Nam để cùng rà soát.