Không nên trước khi xác định cửa sổ lỗi và cơ chế chống trùng. Chụp dữ liệu, đối soát mã đơn nguồn với OMS và chứng từ kho rồi phát lại tập lỗi có kiểm soát. Xem phân tích chi tiết tại: Phục hồi sự cố đồng bộ đơn và tồn kho: runbook OMS + WMS, chống trùng và cổng mở bán lại.

Bảo vệ bán trước, rồi phục hồi đơn, hủy và chứng từ kho để tính lại tồn khả dụng. Không lấy số tồn cũ đè lên nguồn. Xem phân tích chi tiết tại: Phục hồi sự cố đồng bộ đơn và tồn kho: runbook OMS + WMS, chống trùng và cổng mở bán lại.

Khi đơn nguồn đã được giải trình, không còn giữ hoặc xuất trùng chưa xử lý, tồn công bố được kênh xác nhận và ngoại lệ có chủ. Mở theo nhóm SKU trước khi mở rộng. Xem phân tích chi tiết tại: Phục hồi sự cố đồng bộ đơn và tồn kho: runbook OMS + WMS, chống trùng và cổng mở bán lại.

JST ERP là hệ thống quản lý tài nguyên doanh nghiệp (Enterprise Resource Planning) được thiết kế đặc biệt cho doanh nghiệp thương mại điện tử và bán hàng đa kênh tại Việt Nam. Hệ thống giúp quản lý đơn hàng, kho hàng, tồn kho và vận hành một cách tập trung và hiệu quả.

JST ERP phù hợp với: (1) Shop online mới bắt đầu cần gom đơn từ social/livestream, (2) Doanh nghiệp bán hàng đa kênh (Shopee, Lazada, TikTok Shop, Facebook), (3) Doanh nghiệp có kho riêng cần quy trình kho chuyên nghiệp, (4) Doanh nghiệp muốn mở rộng quy mô và cần hệ thống vận hành chuẩn hóa. Xem phân tích chi tiết tại: Phần mềm OMS + WMS cho ecommerce Việt Nam, Giải pháp fulfillment giao trong ngày bằng OMS + WMS và Giải pháp đối soát COD, phí sàn và hàng hoàn.

JST ERP tập trung vào bài toán thương mại điện tử tại Việt Nam với: (1) Kết nối các kênh bán phổ biến như Shopee, Lazada, TikTok Shop theo phạm vi triển khai, (2) Hỗ trợ livestream và social commerce, (3) Giao diện và tài liệu phù hợp với đội vận hành, (4) Đội ngũ tư vấn và hỗ trợ triển khai tại Việt Nam.

Tính năng chính bao gồm: (1) Quản lý đơn hàng tập trung từ nhiều kênh, (2) Đồng bộ tồn kho real-time, (3) Quản lý kho với quy trình chuẩn (WMS), (4) Tích hợp livestream và gom comment/inbox, (5) Quản lý vận chuyển và đối soát, (6) Báo cáo và phân tích dữ liệu, (7) Quản lý sản phẩm và danh mục. Xem phân tích chi tiết tại: Phần mềm OMS + WMS cho ecommerce Việt Nam, SLA đồng bộ tồn kho đa sàn, Giải pháp fulfillment giao trong ngày bằng OMS + WMS, Giải pháp đối soát COD, phí sàn và hàng hoàn và Chi phí và ROI WMS cho ecommerce Việt Nam.

Có. JST ERP hỗ trợ gom comment, inbox từ livestream Facebook, TikTok. Hệ thống tự động chuyển comment thành đơn hàng, giúp đội bán hàng xử lý nhanh hơn và giảm thiểu sai sót.

JST ERP tích hợp với: (1) Sàn TMĐT: Shopee, Lazada, TikTok Shop, Sendo, (2) Social: Facebook, Instagram, Zalo, (3) Vận chuyển: Giao Hàng Nhanh, Giao Hàng Tiết Kiệm, Viettel Post, J&T, (4) Thanh toán: VNPay, MoMo, ZaloPay, (5) Thiết bị kho: PDA, máy quét mã vạch.

Có. JST ERP hỗ trợ quản lý nhiều kho và chi nhánh theo phạm vi triển khai. Phân bổ đơn không nên chỉ dựa vào kho gần nhất mà cần kiểm tồn khả dụng, SLA, công suất, chi phí và khả năng xử lý của kho. Xem phân tích chi tiết tại: Phân bổ đơn đa kho bằng OMS + WMS.

Hãy lọc kho đủ tồn khả dụng, capability, công suất và cut-off trước; sau đó mới xếp hạng theo khả năng hoàn tất toàn bộ đơn, SLA, tổng chi phí và khoảng cách. Xem phân tích chi tiết tại: Phân bổ đơn đa kho bằng OMS + WMS.

Chỉ nên split khi giá trị giữ đơn hoặc SLA lớn hơn cước, đóng gói, hàng hoàn, COD và rủi ro trải nghiệm bổ sung; cần giới hạn số kiện và loại đơn. Xem phân tích chi tiết tại: Phân bổ đơn đa kho bằng OMS + WMS.

OMS cần reservation có mã duy nhất, thời hạn, trạng thái và idempotency; WMS chỉ phát task cho allocation đang hiệu lực và phải reverse task cũ trước khi re-route. Xem phân tích chi tiết tại: Phân bổ đơn đa kho bằng OMS + WMS. Xem phân tích chi tiết tại: Quản lý tồn kho combo đa kênh: SKU thành phần, kitting và OMS + WMS.

Nên đo riêng độ trễ nhận đơn, giữ tồn và kênh xác nhận; dùng P95/P99, tỷ lệ thành công, backlog quá hạn, tuổi bản ghi cũ nhất, duplicate, missing event và chênh lệch OMS–kênh–WMS. Xem phân tích chi tiết tại: SLA đồng bộ tồn kho đa sàn.

Không. Mỗi con số chỉ là giới hạn khi xét riêng một combo. Quy đổi combo và đơn bán lẻ về nhu cầu từng SKU, rồi kiểm tổng phân bổ không vượt tồn khả dụng. Xem phân tích chi tiết tại: Quản lý tồn kho combo đa kênh: SKU thành phần, kitting và OMS + WMS.

Không. Thành phần đưa vào bộ phải được chuyển đổi hoặc giữ khỏi nguồn hàng rời tự do; không tính cùng lượng hàng đồng thời là bộ và thành phần bán lẻ. Xem phân tích chi tiết tại: Quản lý tồn kho combo đa kênh: SKU thành phần, kitting và OMS + WMS.

Nhập theo từng SKU thực nhận vào khu chờ kiểm; chỉ món đạt QC được mở bán. Món thiếu là ngoại lệ, không nhập lại nguyên bộ chỉ vì đã hoàn tiền. Xem phân tích chi tiết tại: Quản lý tồn kho combo đa kênh: SKU thành phần, kitting và OMS + WMS.

Buffer nên dựa trên tốc độ bán trong cửa sổ rủi ro, độ trễ P95/P99, campaign, độ chính xác kho và khả năng dừng bán; không có một mức 2–3 sản phẩm phù hợp mọi SKU. Xem phân tích chi tiết tại: SLA đồng bộ tồn kho đa sàn và Tồn kho an toàn cho ecommerce: ROP, campaign và OMS + WMS. Xem phân tích chi tiết tại: Quản lý tồn kho combo đa kênh: SKU thành phần, kitting và OMS + WMS.

Nên so ROP với inventory position: tồn bán được cộng inbound đã xác nhận, trừ reservation và backorder; không dùng riêng on-hand vì có thể chứa hàng bị khóa hoặc bỏ sót hàng đang về. Xem phân tích chi tiết tại: Tồn kho an toàn cho ecommerce.

Nên bắt đầu từ khoảng T-45: chốt dự báo và SKU campaign ở T-45 đến T-30, hẹn lịch nhập muộn nhất khoảng T-10, tuyển và đào tạo thời vụ từ T-21, diễn tập tải ở T-7 và đóng băng thay đổi từ T-5; quyết định đổi phương pháp kho nên chốt trước T-14. Xem phân tích chi tiết tại: Kế hoạch vận hành kho mùa sale 11.11, 12.12: tính tải giờ, nút nghẽn và timeline T-45 bằng OMS + WMS.

Phân bổ dự báo theo đường cong giờ của đợt sale trước, cộng backlog, rồi chia cho số giờ làm việc hữu dụng trước chuyến xe cuối còn kịp deadline; cộng biên 15–25% và so với công suất nút chậm nhất, thường là bàn đóng gói. Xem phân tích chi tiết tại: Kế hoạch vận hành kho mùa sale 11.11, 12.12: tính tải giờ, nút nghẽn và timeline T-45 bằng OMS + WMS.

Giao việc có quét mã xác nhận và ít quyết định như đóng gói đơn đã kiểm, dán nhãn, gom kiện theo đơn vị vận chuyển, pre-pack theo lệnh; giữ kiểm hàng độc lập, xử lý thiếu hàng, điều chỉnh tồn và hàng hoàn cho nhân sự cố định. Xem phân tích chi tiết tại: Kế hoạch vận hành kho mùa sale 11.11, 12.12: tính tải giờ, nút nghẽn và timeline T-45 bằng OMS + WMS.

Không. Campaign uplift nên là lớp có lịch, xác suất, ngân sách, trần bán và owner riêng; trộn toàn bộ vào safety stock sẽ làm baseline phình lên và tạo tồn dư sau sale. Xem phân tích chi tiết tại: Tồn kho an toàn cho ecommerce. Xem phân tích chi tiết tại: Kế hoạch vận hành kho mùa sale 11.11, 12.12: tính tải giờ, nút nghẽn và timeline T-45 bằng OMS + WMS.

OMS-only có thể đủ khi tồn, reservation và inbound đáng tin. Nếu receiving, QC, putaway, bin, lot/date, return, nhiều kho hoặc 3PL làm thay đổi hàng bán được, cần OMS + WMS hoặc nguồn bằng chứng kho tương đương. Xem phân tích chi tiết tại: Tồn kho an toàn cho ecommerce và Quy trình nhập kho ecommerce bằng OMS + WMS.

Chỉ sau khi đúng SKU, số lượng, tình trạng và thuộc tính bắt buộc đã được xác nhận, ngoại lệ được tách, đồng thời hàng đã tới vị trí hoặc trạng thái mà chính sách cho phép bán. Ký nhận xe hay tạo phiếu nhập chưa đủ. Xem phân tích chi tiết tại: Quy trình nhập kho ecommerce bằng OMS + WMS.

Blind count là kiểm đếm mà người đếm không nhìn trước số lượng kỳ vọng; sau khi chốt lượt đếm, hệ thống mới so với PO hoặc ASN. Cách này giảm xu hướng nhập theo chứng từ thay vì hàng thực nhận. Xem phân tích chi tiết tại: Quy trình nhập kho ecommerce bằng OMS + WMS.

Với kho quản lý theo bin, nên xác nhận handling unit hoặc SKU nguồn, vị trí đích và lượng thực đặt; trường hợp rủi ro trộn mã cao cần quét SKU tại điểm đặt. Chỉ quét hàng không chứng minh hàng đang ở bin nào. Xem phân tích chi tiết tại: Quy trình nhập kho ecommerce bằng OMS + WMS.

Chỉ tiếp tục với SKU có buffer và mức rủi ro cho phép; khi dữ liệu stale vượt ngưỡng, nên giảm tồn công bố, đóng SKU tồn thấp/campaign hoặc chuyển manual approval theo degraded-mode policy. Xem phân tích chi tiết tại: SLA đồng bộ tồn kho đa sàn. Xem phân tích chi tiết tại: Phục hồi sự cố đồng bộ đơn và tồn kho: runbook OMS + WMS, chống trùng và cổng mở bán lại.

Không có một tỷ lệ phù hợp cho mọi kho. Hãy đo riêng độ đúng theo SKU, vị trí và trạng thái; đặt ngưỡng chặt hơn cho SKU bán nhanh, giá trị cao, tồn thấp và SKU đang chạy campaign. Xem phân tích chi tiết tại: Độ chính xác tồn kho ecommerce.

Cycle count kiểm một nhóm SKU hoặc vị trí theo lịch hay tín hiệu rủi ro nên ít gián đoạn hơn; kiểm kê toàn kho chốt toàn bộ phạm vi tại một thời điểm. Xem phân tích chi tiết tại: Độ chính xác tồn kho ecommerce. Xem phân tích chi tiết tại: Kiểm soát thất thoát tồn kho ecommerce.

Có thể bắt đầu bằng SKU A hoặc rủi ro cao hằng ngày-hằng tuần, SKU B hằng tháng và SKU C hằng quý; sau đó điều chỉnh theo tốc độ bán, giá trị, sai lệch, hàng hoàn và campaign. Xem phân tích chi tiết tại: Độ chính xác tồn kho ecommerce.

Nên cố định một công thức và một mẫu số: giá trị hàng mất theo giá vốn trừ phần thu hồi được, chia cho giá vốn hàng bán trong cùng kỳ. Tách riêng theo nguyên nhân và không gộp hàng mẫu, quà tặng hay lỗi dữ liệu vào thất thoát. Xem phân tích chi tiết tại: Kiểm soát thất thoát tồn kho ecommerce.

Nhân viên kho nên được quyền ghi nhận phát hiện lệch kèm bằng chứng, còn thay đổi số dư nên đi qua phiếu có reason code và người duyệt khác người tạo, theo ngưỡng giá trị. Cần thêm quy tắc cộng dồn trong 24 giờ để chặn việc chia nhỏ phiếu. Xem phân tích chi tiết tại: Kiểm soát thất thoát tồn kho ecommerce.

Nên tách riêng thành tổn thất vận chuyển và đưa vào quy trình khiếu nại có thời hạn, với manifest, bằng chứng bàn giao và video đóng gói. Gộp chung vào thất thoát kho sẽ làm sai chỉ số của kho và thường làm mất quyền đòi bồi thường. Xem phân tích chi tiết tại: Kiểm soát thất thoát tồn kho ecommerce.

OMS-only phù hợp khi ít đơn, ít SKU và một kho nhỏ. Khi cần PDA, barcode, bin location, wave picking, checking, packing, staging và bàn giao 3PL, nên dùng OMS + WMS. Xem phân tích chi tiết tại: Giải pháp fulfillment giao trong ngày bằng OMS + WMS, Kiểm soát SLA marketplace, Thiết kế layout kho ecommerce và Định biên nhân sự kho ecommerce. Xem phân tích chi tiết tại: Chiến lược lấy hàng kho ecommerce: theo đơn, batch, wave hay zone.

Không có một con số cố định; tín hiệu đúng là hình dạng đơn. Khi phần lớn đơn chỉ có 1–2 dòng và nhiều đơn trong cùng khung giờ trùng SKU, batch bắt đầu có lợi. Hãy so số lần ghé vị trí tiết kiệm được với thời gian phân đơn phát sinh trên dữ liệu 14 ngày. Xem phân tích chi tiết tại: Chiến lược lấy hàng kho ecommerce: theo đơn, batch, wave hay zone.

Batch gom nhiều đơn vào một lượt lấy để giảm quãng đường; wave chia đơn thành các đợt phát hành theo mốc cắt giờ của sàn hoặc giờ xe của đơn vị vận chuyển. Một wave có thể chứa nhiều batch. Xem phân tích chi tiết tại: Chiến lược lấy hàng kho ecommerce: theo đơn, batch, wave hay zone.

Có, nếu không có bước phân đơn có quét mã. Khi batch, món hàng chỉ được gán cho đơn ở bàn phân đơn, nên cần quét từng món khi phân, khóa đơn khi thiếu món và xử lý short pick tại chỗ. Xem phân tích chi tiết tại: Chiến lược lấy hàng kho ecommerce: theo đơn, batch, wave hay zone.

Nên tính từng đơn theo deadline áp dụng cho chính đơn đó rồi tổng hợp theo đúng cửa sổ và mẫu số của từng sàn. Cần xét cut-off, loại fulfillment, ngày làm việc và policy version. Xem phân tích chi tiết tại: Kiểm soát SLA marketplace.

Không nên. In nhãn chỉ chứng minh đã tạo chứng từ; bằng chứng mạnh hơn là scan picking, checking, packing, staging, manifest và carrier acceptance. Event nào được sàn tính phải theo policy hiện hành. Xem phân tích chi tiết tại: Kiểm soát SLA marketplace.

Ưu tiên theo slack time, deadline, phút xử lý còn lại, khả năng cứu đơn và carrier cut-off; không chỉ theo đơn cũ nhất. Đơn thiếu hàng hoặc không thể kịp cần chuyển sang exception sớm. Xem phân tích chi tiết tại: Kiểm soát SLA marketplace.

Cut-off nên dựa trên giờ lấy hàng của hãng vận chuyển, số đơn đang chờ, năng lực kho còn lại, nhóm SKU khó xử lý, đơn COD cần xác nhận và khoảng đệm cho ngoại lệ. Xem phân tích chi tiết tại: Giải pháp fulfillment giao trong ngày bằng OMS + WMS.

Vẫn cần lớp OMS để quyết định đơn, tồn, SLA, COD và trách nhiệm; WMS hoặc tích hợp 3PL giúp trả trạng thái picking, packing, mã kiện, bàn giao và tồn khả dụng rõ hơn. Xem phân tích chi tiết tại: SLA 3PL fulfillment ecommerce, Giải pháp fulfillment giao trong ngày bằng OMS + WMS và Kho tự vận hành hay thuê 3PL fulfillment?.

Nên ưu tiên 3PL khi cần mở nhanh, sản lượng biến động, chưa muốn đầu tư đội kho hoặc cần phủ nhiều vùng; vẫn phải kiểm tổng chi phí, SLA, tồn, hàng hoàn và điều khoản trách nhiệm. Xem phân tích chi tiết tại: Kho tự vận hành hay thuê 3PL fulfillment? và SLA 3PL fulfillment ecommerce.

Không có một ngưỡng đơn chung. Điểm hòa vốn phụ thuộc chi phí cố định, số dòng hàng, độ phức tạp SKU, tỷ lệ hoàn, sản lượng peak và đơn giá 3PL; cần tính theo tháng và kiểm thêm công suất theo giờ. Xem phân tích chi tiết tại: Kho tự vận hành hay thuê 3PL fulfillment?.

Hybrid phù hợp khi cần giữ SKU hoặc đơn phức tạp ở kho nội bộ nhưng dùng 3PL cho vùng xa, SKU chuẩn, tải peak hoặc kho dự phòng; OMS phải quản lý phân kho và tồn khả dụng chung. Xem phân tích chi tiết tại: Kho tự vận hành hay thuê 3PL fulfillment?.

Tối thiểu nên có receiving, inventory accuracy, order ACK, pick-check-pack, bàn giao carrier, return receiving, return QC, claim, API và capacity peak; mỗi chỉ số phải có start, stop, mẫu số, ngoại lệ, evidence và owner. Xem phân tích chi tiết tại: SLA 3PL fulfillment ecommerce và Quy trình nhập kho ecommerce bằng OMS + WMS.

Nên dùng tỷ lệ đúng hạn cùng P90/P95 và backlog aging; thời gian trung bình có thể bị nhiều đơn nhanh che phần đuôi đơn rất trễ. Xem phân tích chi tiết tại: SLA 3PL fulfillment ecommerce.

OMS cần request ID, timestamp và retry; 3PL phải trả ACK hoặc reject có reason. Không có ACK thì đơn vào queue ngoại lệ với owner và escalation, không được mặc định là đã nhận. Xem phân tích chi tiết tại: SLA 3PL fulfillment ecommerce.

Nên bắt đầu từ đơn hàng và mã vận đơn, sau đó nối sang file settlement, phí sàn, COD, refund và WMS return. Xem phân tích chi tiết tại: Giải pháp đối soát COD, phí sàn và hàng hoàn, Quản lý hàng hoàn ecommerce: cost-to-recover, SLA QC và OMS + WMS, Lợi nhuận thật từng đơn ecommerce và Đối soát dòng tiền ecommerce bằng 4-way match. Xem phân tích chi tiết tại: Hóa đơn điện tử, thuế sàn khấu trừ và dữ liệu kế toán cho ecommerce.

OMS-only phù hợp khi chỉ cần nối order, settlement và bank với hàng hoàn đơn giản. Khi hàng hoàn cần QC, barcode, bin location, nhiều kho hoặc 3PL, nên dùng OMS + WMS. Xem phân tích chi tiết tại: Giải pháp đối soát COD, phí sàn và hàng hoàn, Lợi nhuận thật từng đơn ecommerce và Đối soát dòng tiền ecommerce bằng 4-way match.

Nên khớp ít nhất tới order line và settlement transaction; tổng tiền chỉ dùng làm control total vì khoản thừa có thể che khoản thiếu. Xem phân tích chi tiết tại: Đối soát dòng tiền ecommerce bằng 4-way match.

Gồm order/order line trong OMS, transaction settlement của sàn hoặc 3PL, tiền thực nhận tại ví/ngân hàng/COD và bằng chứng giao–hoàn–QC trong WMS. Xem phân tích chi tiết tại: Đối soát dòng tiền ecommerce bằng 4-way match.

Có thể auto-classify trong tolerance được duyệt nhưng không xóa dấu vết; phải giữ số tiền, reason, lũy kế, owner và quyền phê duyệt. Xem phân tích chi tiết tại: Đối soát dòng tiền ecommerce bằng 4-way match.

Chỉ nên gọi là lợi nhuận thực hiện khi các khoản thu–phí chính đã được settlement, giá vốn và chi phí vận hành đã khóa theo quy tắc, đồng thời return/refund/claim đã hết cửa sổ hoặc được accrual rõ ràng. Xem phân tích chi tiết tại: Lợi nhuận thật từng đơn ecommerce. Xem phân tích chi tiết tại: Hóa đơn điện tử, thuế sàn khấu trừ và dữ liệu kế toán cho ecommerce.

Doanh số có thể gồm đơn chưa thanh toán, hủy hoặc hoàn; tiền thực nhận còn bị trừ voucher do shop chịu, phí sàn, vận chuyển, refund, quảng cáo, claim và chi phí kho. Xem phân tích chi tiết tại: Lợi nhuận thật từng đơn ecommerce.

Tách refund tài chính khỏi trạng thái hàng vật lý; chỉ hoàn nhập phần giá vốn có thể phục hồi sau khi WMS scan đúng return line, QC và gán disposition. Xem phân tích chi tiết tại: Lợi nhuận thật từng đơn ecommerce. Xem phân tích chi tiết tại: Hóa đơn điện tử, thuế sàn khấu trừ và dữ liệu kế toán cho ecommerce.

Nguyên tắc chung với hàng hóa là lập hóa đơn khi chuyển giao quyền sở hữu hoặc quyền sử dụng, không phụ thuộc đã thu tiền. Doanh nghiệp cần kế toán chốt một mốc vận hành tương ứng (thường là giao thành công hoặc bàn giao vận chuyển), ghi thành quy tắc trong OMS, dùng một khóa hóa đơn duy nhất cho mỗi đơn để chống xuất trùng và theo dõi tuổi của yêu cầu chưa phát hành. Xem phân tích chi tiết tại: Hóa đơn điện tử, thuế sàn khấu trừ và dữ liệu kế toán cho ecommerce.

Theo Nghị định 117/2025/NĐ-CP, từ 1/7/2025 sàn có chức năng thanh toán khấu trừ thuế cho hộ và cá nhân kinh doanh; doanh nghiệp tự kê khai. Shop vẫn nên đối chiếu thuế khấu trừ theo từng đơn, tổng theo kỳ với chứng từ khấu trừ, và theo dõi đơn hoàn tiền sau khi đã khấu trừ. Nghĩa vụ cụ thể cần kế toán hoặc tư vấn thuế xác nhận. Xem phân tích chi tiết tại: Hóa đơn điện tử, thuế sàn khấu trừ và dữ liệu kế toán cho ecommerce.

Theo hàng nhận về. Chứng từ điều chỉnh chỉ nên tạo khi WMS đã quét nhận đúng dòng hàng hoàn, với số tiền bằng giá dòng sau khi đã trừ phần voucher phân bổ; hoàn tiền không cần trả hàng được xử lý theo quyết định riêng của kế toán. Xem phân tích chi tiết tại: Hóa đơn điện tử, thuế sàn khấu trừ và dữ liệu kế toán cho ecommerce.

Không nên dùng riêng số đơn. Nhân số đơn/ngày với số kênh hoặc gian hàng dùng chung tồn: khi tích vượt khoảng 150–200, hoặc từ 2 người cùng sửa tồn, hoặc chi phí lỗi mỗi tháng lớn hơn phí phần mềm, Excel đã đắt hơn hệ thống. Xem phân tích chi tiết tại: Khi nào bỏ Excel để chuyển sang OMS hay OMS + WMS: ngưỡng theo đơn, SKU, kênh và chi phí lỗi.

Bắt đầu bằng OMS khi lỗi chủ yếu là gom đơn, bán vượt tồn giữa các sàn, mapping SKU và đối soát. Cần OMS + WMS khi lỗi nằm trong kho: lấy sai biến thể, tìm hàng lâu, hàng hoàn không vào lại tồn, nhiều kho hoặc có nhân viên mới, thời vụ. Xem phân tích chi tiết tại: Khi nào bỏ Excel để chuyển sang OMS hay OMS + WMS: ngưỡng theo đơn, SKU, kênh và chi phí lỗi.

Cộng bốn khoản theo tháng: đơn hủy do bán vượt tồn, đơn giao sai (ship hai chiều, hàng hỏng, công xử lý), tiền COD/phí sàn lệch không đòi lại được, và giờ công chép, đối chiếu file; so với phí phần mềm cộng chi phí triển khai chia 12 tháng. Xem phân tích chi tiết tại: Khi nào bỏ Excel để chuyển sang OMS hay OMS + WMS: ngưỡng theo đơn, SKU, kênh và chi phí lỗi.

OMS-only phù hợp khi điểm nghẽn chính là gom đơn, SKU mapping, tồn khả dụng và trạng thái đơn; nếu lỗi nằm ở picking, checking, packing, hàng hoàn, barcode, PDA hoặc nhiều kho thì nên đánh giá OMS + WMS. Xem phân tích chi tiết tại: Phần mềm OMS + WMS cho ecommerce Việt Nam và Chuẩn hóa master data SKU, barcode và mapping đa sàn. Xem phân tích chi tiết tại: Chiến lược lấy hàng kho ecommerce: theo đơn, batch, wave hay zone. Xem phân tích chi tiết tại: Khi nào bỏ Excel để chuyển sang OMS hay OMS + WMS: ngưỡng theo đơn, SKU, kênh và chi phí lỗi. Xem phân tích chi tiết tại: Công cụ quản lý đa sàn, OMS + WMS hay ERP: chọn theo lớp vận hành đang hỏng.

Công cụ đa sàn mạnh ở lớp kênh: listing, gom đơn, đồng bộ tồn, in nhãn, chat. OMS + WMS là lớp thực thi: tồn khả dụng, mapping SKU, phân bổ đơn, và trong kho là vị trí, lấy, kiểm, đóng gói, bàn giao, hàng hoàn bằng quét barcode/PDA có nhật ký. Khác biệt kiểm tra được: hệ thống có chặn đóng gói khi quét sai biến thể hay không. Xem phân tích chi tiết tại: Công cụ quản lý đa sàn, OMS + WMS hay ERP: chọn theo lớp vận hành đang hỏng.

Khi lỗi nằm trong kho thay vì giữa các sàn: giao sai biến thể trên khoảng 0,3–0,5% đơn, tìm hàng hơn 1–2 phút mỗi dòng, hàng hoàn chờ quá 48 giờ mới vào lại tồn, lệch tồn sau kiểm kê trên 1–2% giá trị, hoặc có thời vụ phải nhớ vị trí. Khi đó cần WMS theo quét. Xem phân tích chi tiết tại: Công cụ quản lý đa sàn, OMS + WMS hay ERP: chọn theo lớp vận hành đang hỏng.

Thường chưa, nếu tồn và đơn còn sai, vì giá vốn và lãi đơn tính từ tồn. Thứ tự hợp lý: chuẩn SKU và tồn bằng OMS, đưa kho vào quét bằng WMS, rồi nối kế toán bằng bộ số kiểm soát theo kỳ. Cần ERP sớm khi có sản xuất, nhập khẩu phân bổ giá vốn hoặc bán sỉ công nợ. Xem phân tích chi tiết tại: Công cụ quản lý đa sàn, OMS + WMS hay ERP: chọn theo lớp vận hành đang hỏng.

FIFO xuất lô nhập trước, FEFO xuất lô hết hạn trước. Hai cách lệch nhau khi nhận hàng từ nhiều nhà cung cấp, nhận lại hàng hoàn hoặc nhập bù lô cũ. Với hàng có hạn dùng phải dùng FEFO và kiểm tra bằng quét lô khi lấy hàng, không chỉ in gợi ý trên phiếu. Xem phân tích chi tiết tại: Quản lý lô và hạn sử dụng FEFO cho kho ecommerce.

Tính theo công thức: số ngày khách dùng hết + thời gian giao + thời gian đổi trả + đệm, quy ra phần trăm hạn dùng còn lại. Mỹ phẩm hạn dài thường khoảng 25–35%, thực phẩm khô 30–50%, mẹ và bé 40–50%. Lô dưới ngưỡng rút khỏi tồn đẩy lên listing thường và bán ở listing cận date có ghi rõ hạn dùng. Xem phân tích chi tiết tại: Quản lý lô và hạn sử dụng FEFO cho kho ecommerce.

OMS đủ khi mỗi SKU một vị trí, thường một lô đang bán, đơn dưới khoảng 30 mỗi ngày và người lấy hàng cố định. Khi một SKU có nhiều lô ở nhiều vị trí, có thời vụ, combo hoặc hàng hoàn nhiều, cần WMS bắt quét lô và chặn lô sai khi lấy hàng. Xem phân tích chi tiết tại: Quản lý lô và hạn sử dụng FEFO cho kho ecommerce.

Nên chuẩn bị kênh bán, số đơn, SKU master, barcode, tồn theo kho, sơ đồ vị trí, file đối soát, quy trình hàng hoàn và 10-20 đơn lỗi thật để demo sát vận hành. Xem phân tích chi tiết tại: Phần mềm OMS + WMS cho ecommerce Việt Nam và Chuẩn hóa master data SKU, barcode và mapping đa sàn. Xem phân tích chi tiết tại: Chọn và nghiệm thu OMS + WMS: kịch bản POC, bảng chấm điểm và hợp đồng.

Thường 2-4 tuần với phạm vi đóng: một kho, một đến hai sàn, 30-80 SKU chọn có chủ đích và một danh sách kịch bản đã viết ngưỡng đạt từ trước. Bắt buộc có kịch bản nhập danh mục SKU thật chưa làm sạch, ít nhất một ngoại lệ vận hành, một luồng hàng hoàn và một yêu cầu thay đổi để đo tốc độ phản hồi. POC không có tiêu chí đạt viết trước chỉ là demo dài ngày. Xem phân tích chi tiết tại: Chọn và nghiệm thu OMS + WMS: kịch bản POC, bảng chấm điểm và hợp đồng.

Không bắt buộc. Nên giữ một canonical SKU nội bộ ổn định và ánh xạ seller SKU cùng item/model ID của từng shop bằng quan hệ có hiệu lực, lịch sử và người duyệt. Xem phân tích chi tiết tại: Chuẩn hóa master data SKU, barcode và mapping đa sàn.

Chỉ nên tự động khi mã duy nhất và các thuộc tính vật lý bắt buộc cùng khớp; tên giống nhau, mã trống, mã trùng, khác size, màu, UOM, combo hoặc condition phải vào hàng chờ kiểm. Xem phân tích chi tiết tại: Chuẩn hóa master data SKU, barcode và mapping đa sàn.

Không sửa đè khóa đang hoạt động. Cần tạo alias hoặc mapping có phiên bản, xử lý reservation và task mở, chuyển tồn bằng chứng từ có control total, rồi chỉ ngừng mã cũ sau đối soát. Xem phân tích chi tiết tại: Chuẩn hóa master data SKU, barcode và mapping đa sàn.

Công cụ đa sàn thường mạnh ở kết nối gian hàng, gom đơn và đồng bộ tồn; OMS + WMS đi sâu hơn vào giữ tồn, phân kho, barcode, PDA, bin location, return QC, đối soát trách nhiệm và go-live dữ liệu. Xem phân tích chi tiết tại: Phần mềm OMS + WMS cho ecommerce Việt Nam.

Cần tách trạng thái tài chính và trạng thái hàng vật lý; đơn có thể đã quyết toán nhưng vẫn nằm trong hàng đợi return in transit cho đến khi WMS scan nhận hàng và QC. Xem phân tích chi tiết tại: Giải pháp đối soát COD, phí sàn và hàng hoàn và Quản lý hàng hoàn ecommerce: cost-to-recover, SLA QC và OMS + WMS.

Chỉ sau khi kho scan nhận đúng kiện, đối chiếu đúng SKU hoặc serial, hoàn tất QC và gán disposition sellable. Trạng thái carrier giao về hoặc refund hoàn tất không đủ để cộng ATP. Xem phân tích chi tiết tại: Quản lý hàng hoàn ecommerce: cost-to-recover, SLA QC và OMS + WMS.

Hãy so giá trị có thể phục hồi với cước chiều về, xử lý, QC, rework, khấu hao và rủi ro; chỉ tự động hóa trong phạm vi SKU, giá trị, lý do và tần suất đã được duyệt. Xem phân tích chi tiết tại: Quản lý hàng hoàn ecommerce: cost-to-recover, SLA QC và OMS + WMS.

Mỗi return line cần mã duy nhất và event có idempotency; refund, carrier delivery và WMS receiving là các sự kiện riêng, chỉ disposition sellable được tạo một bút toán tăng tồn. Xem phân tích chi tiết tại: Quản lý hàng hoàn ecommerce: cost-to-recover, SLA QC và OMS + WMS.

JST ERP Việt Nam tư vấn theo 2 phạm vi chính: (1) OMS: quản lý đơn hàng, sản phẩm, tồn kho, shop và kênh bán đa nền tảng, (2) OMS + WMS: bổ sung quản lý kho thực địa như khu vực, vị trí, PDA, picking, checking, packing và kiểm kê. Chi tiết giá vui lòng liên hệ để được tư vấn phù hợp.

Có. Doanh nghiệp có thể đăng ký để trao đổi nhu cầu, xem demo theo bài toán vận hành và xác nhận hình thức trải nghiệm phù hợp với phạm vi OMS hoặc OMS + WMS.

Chi phí triển khai phụ thuộc vào phạm vi OMS hoặc OMS + WMS, số kho và người dùng, dữ liệu, tích hợp, thiết bị, đào tạo và hỗ trợ go-live. Doanh nghiệp nên yêu cầu báo giá theo phạm vi khảo sát thay vì chỉ so phí thuê bao. Xem phân tích chi tiết tại: Chi phí và ROI WMS cho ecommerce Việt Nam. Xem phân tích chi tiết tại: Chọn và nghiệm thu OMS + WMS: kịch bản POC, bảng chấm điểm và hợp đồng.

Gửi cho mọi nhà cung cấp cùng một biểu mẫu báo giá do doanh nghiệp thiết kế, thay vì nhận về nhiều định dạng khác nhau rồi cố ghép. Biểu mẫu nên có dòng riêng cho: phí triển khai và số ngày công bao gồm, tích hợp từng sàn và từng đơn vị vận chuyển, làm sạch và chuyển đổi dữ liệu, thiết bị, đào tạo, chạy song song, đơn giá yêu cầu thay đổi sau go-live, phí theo mức sử dụng khi vượt ngưỡng, và thời gian nhân sự nội bộ. Xem phân tích chi tiết tại: Chọn và nghiệm thu OMS + WMS: kịch bản POC, bảng chấm điểm và hợp đồng.

Ba điều khoản: đơn giá và thời hạn phản hồi cho yêu cầu thay đổi sau go-live, cách lấy toàn bộ dữ liệu ra khi kết thúc hợp đồng (định dạng, phạm vi lịch sử, thời hạn, chi phí), và thời gian phản hồi hỗ trợ phân theo mức độ nghiêm trọng của sự cố. Nên kiểm tra khả năng xuất dữ liệu ngay trong POC thay vì tin cam kết bằng lời. Mọi câu chữ hợp đồng cần luật sư rà soát trước khi ký. Xem phân tích chi tiết tại: Chọn và nghiệm thu OMS + WMS: kịch bản POC, bảng chấm điểm và hợp đồng.

WMS bắt đầu hoàn vốn khi lợi ích tích lũy từ nhân công, lỗi kho, tồn lệch, SLA và hàng hoàn lớn hơn tổng chi phí phần mềm, dữ liệu, tích hợp, thiết bị, đào tạo và vận hành. Xem phân tích chi tiết tại: Chi phí và ROI WMS cho ecommerce Việt Nam.

TCO nên gồm phí phần mềm, khảo sát quy trình, làm sạch SKU và barcode, tích hợp, PDA và máy in, đào tạo, chạy song song, hỗ trợ go-live, admin dài hạn và dự phòng thay đổi. Khi so với 3PL, cần cộng thêm lưu kho, inbound, pick-pack, vật tư, hàng hoàn, claim, minimum, line-haul và phí thoát. Xem phân tích chi tiết tại: Chi phí và ROI WMS cho ecommerce Việt Nam và Kho tự vận hành hay thuê 3PL fulfillment?.

OMS-only phù hợp khi chi phí chủ yếu nằm ở gom đơn, giữ tồn và phân kho. Nếu lỗi phát sinh ở bin location, barcode, picking, checking, packing, kiểm kê hoặc return QC, nên đánh giá OMS + WMS. Xem phân tích chi tiết tại: Chi phí và ROI WMS cho ecommerce Việt Nam, Thiết kế layout kho ecommerce và Định biên nhân sự kho ecommerce.

Không có một con số chung. Hãy đổi từng loại đơn thành phút receiving, replenishment, picking, checking, packing và bàn giao; cộng thời gian gián tiếp cùng buffer rồi chia theo phút làm việc hữu dụng trong đúng cửa sổ SLA. Xem phân tích chi tiết tại: Định biên nhân sự kho ecommerce. Xem phân tích chi tiết tại: Chiến lược lấy hàng kho ecommerce: theo đơn, batch, wave hay zone. Xem phân tích chi tiết tại: Kế hoạch vận hành kho mùa sale 11.11, 12.12: tính tải giờ, nút nghẽn và timeline T-45 bằng OMS + WMS.

Order line phản ánh số lần chạm SKU tốt hơn số đơn, nhưng vẫn phải tách single-line, multi-line, combo, bulky, serial và return; khi độ khó khác lớn nên dùng standard minute hoặc weighted workload. Xem phân tích chi tiết tại: Định biên nhân sự kho ecommerce.

Không. Nên dùng time study đã phân tầng order profile, method chuẩn và nhịp bền vững; đồng thời giữ allowance hợp lệ cho an toàn, nghỉ và bàn giao. Xem phân tích chi tiết tại: Định biên nhân sự kho ecommerce.

Không có một tỷ lệ chung. Hãy trừ receiving, QC, packing, staging, hàng hoàn, lối đi, an toàn và buffer trước; sau đó kiểm tra bằng lưu lượng giờ peak. Xem phân tích chi tiết tại: Thiết kế layout kho ecommerce.

Nên tách khi SKU bán nhanh tạo nhiều lượt lấy nhưng không cần toàn bộ tồn ở mặt pick. Bulk giữ tồn dự trữ, forward-pick giữ lượng đủ đến lần replenishment kế tiếp. Xem phân tích chi tiết tại: Thiết kế layout kho ecommerce.

Nên xét order lines, lượt chạm, cube velocity, kích thước, trọng lượng, affinity, batch/FEFO, rủi ro nhầm SKU và tần suất replenishment, không chỉ dựa vào doanh thu. Xem phân tích chi tiết tại: Thiết kế layout kho ecommerce. Xem phân tích chi tiết tại: Quản lý lô và hạn sử dụng FEFO cho kho ecommerce.

Không. JST ERP minh bạch về giá cả. Chi phí bao gồm: (1) Phí đăng ký hàng tháng/năm, (2) Phí triển khai ban đầu (nếu có), (3) Phí tùy chỉnh (nếu có yêu cầu đặc biệt). Tất cả được thỏa thuận rõ ràng trong hợp đồng.

Thời gian triển khai phụ thuộc vào phạm vi: OMS thường nhanh hơn vì tập trung vào đơn hàng, sản phẩm, tồn kho và kênh bán; OMS + WMS cần thêm khảo sát kho, thiết kế khu vực / vị trí, cấu hình PDA, quy trình picking, checking, packing, kiểm kê và đào tạo nhân sự kho. Thời gian cụ thể nên xác nhận sau khảo sát. Xem phân tích chi tiết tại: Triển khai OMS + WMS không gián đoạn.

Có. Đào tạo nên theo vai trò và dùng tình huống thật cho người dùng, key user và admin; trước go-live cần kiểm tra cả luồng chuẩn lẫn ngoại lệ thay vì chỉ giới thiệu nút bấm. Xem phân tích chi tiết tại: Triển khai OMS + WMS không gián đoạn.

Thông thường doanh nghiệp không cần đội IT chuyên trách để sử dụng các thao tác vận hành hằng ngày. Tuy nhiên, phạm vi cấu hình, tích hợp và phân quyền ban đầu nên được đội JST ERP hướng dẫn để hệ thống đi vào vận hành đúng quy trình.

Có thể hỗ trợ chuyển đổi dữ liệu theo phạm vi thống nhất trước triển khai, thường gồm sản phẩm, thông tin khách hàng, tồn kho và một số dữ liệu vận hành cần thiết. Dữ liệu cần được đối chiếu bằng control total và exception list trước khi sử dụng. Xem phân tích chi tiết tại: Triển khai OMS + WMS không gián đoạn và Chuẩn hóa master data SKU, barcode và mapping đa sàn.

Cần đạt bốn cổng: dữ liệu SKU, barcode, tồn và đơn mở đã đối chiếu; UAT gồm ngoại lệ đã đạt; người dùng và thiết bị sẵn sàng; rollback có trigger, owner và dữ liệu phục hồi rõ. Nên tách rõ danh sách lỗi chặn go-live khỏi danh sách lỗi chấp nhận được có thời hạn sửa, và gắn mốc nghiệm thu cuối với một giai đoạn vận hành ổn định thay vì với ngày bàn giao tài liệu. Xem phân tích chi tiết tại: Triển khai OMS + WMS không gián đoạn. Xem phân tích chi tiết tại: Chọn và nghiệm thu OMS + WMS: kịch bản POC, bảng chấm điểm và hợp đồng.

Nên rollback hoặc cô lập phạm vi khi lỗi chạm ngưỡng đã duyệt, như mất hoặc trùng đơn, tồn phát sai, label lỗi diện rộng, không truy vết được kiện hoặc backlog đe dọa SLA. Xem phân tích chi tiết tại: Triển khai OMS + WMS không gián đoạn.

Chỉ nên chạy song song khi đã chỉ định hệ thống nào được quyền ghi từng nghiệp vụ. Shadow run để so kết quả an toàn hơn việc nhân viên nhập đơn hoặc tồn ở hai nơi. Xem phân tích chi tiết tại: Triển khai OMS + WMS không gián đoạn.

JST ERP hỗ trợ khách hàng theo phạm vi dịch vụ đã thống nhất, bao gồm tư vấn sử dụng, xử lý câu hỏi vận hành và hỗ trợ sau triển khai qua các kênh liên hệ phù hợp như điện thoại, email, Zalo hoặc hệ thống ticket nếu được áp dụng.

JST ERP áp dụng các nguyên tắc bảo mật cần thiết cho hệ thống doanh nghiệp như phân quyền người dùng, kiểm soát truy cập và các cơ chế bảo vệ dữ liệu theo phạm vi triển khai. Các yêu cầu bảo mật chi tiết sẽ được xác nhận trong quá trình tư vấn và hợp đồng dịch vụ.

Đội ngũ phụ trách của JST ERP sẽ hỗ trợ qua các kênh liên hệ chính như điện thoại 0389107376, email yada@jushuitan.com, Zalo hoặc hệ thống ticket nếu được áp dụng. Thời gian phản hồi phụ thuộc mức độ ưu tiên và phạm vi hỗ trợ đã thống nhất.

JST ERP tiếp tục cải tiến sản phẩm theo nhu cầu thị trường và phản hồi vận hành. Các thay đổi ảnh hưởng đến doanh nghiệp sẽ được trao đổi theo chính sách cập nhật và hỗ trợ tương ứng.