Thực chiến: kiểm thử tracking giao hàng & đối soát COD trong logistics chặng cuối

1. Bối cảnh doanh nghiệp & phạm vi

Một sàn giao hàng chặng cuối (last-mile) tại Việt Nam xử lý trung bình 450.000 đơn/ngày trên toàn quốc, trong đó khoảng 62% là đơn thu hộ COD (Cash On Delivery — thanh toán khi nhận hàng), phần còn lại đã thanh toán trước qua ví điện tử hoặc thẻ. Mỗi đơn COD đi qua chuỗi: người bán tạo đơn → hệ thống điều phối (dispatch) gán tài xế/tuyến → tài xế lấy hàng tại kho hoặc điểm gửi → giao đến khách và thu tiền mặt hoặc quét mã chuyển khoản → tài xế nộp lại tiền cho bưu cục hoặc chuyển khoản trực tiếp về ví nội bộ → hệ thống đối soát khớp số tiền thu với số tiền nộp và với giá trị đơn hàng. SLA giao hàng nội thành cam kết 24 giờ, liên tỉnh 48-72 giờ; SLA đối soát COD với người bán là T+2 ngày làm việc kể từ khi đơn chuyển trạng thái giao thành công.

Phạm vi tự động hoá

• API tạo đơn, cập nhật trạng thái, webhook tracking từ tài xế
• Luồng thu hộ COD: ghi nhận thu, nộp về, đối soát batch cuối ngày
• Điều phối/routing: gán tài xế theo khu vực, tải trọng, khung giờ
• Ngoài phạm vi: thuật toán tối ưu tuyến đường chi tiết (do đội Data/OR đảm nhiệm), UI bản đồ

2. Kiến trúc hệ thống & luồng nghiệp vụ

Kiến trúc gồm 5 dịch vụ chính: Order Service (nguồn sự thật về đơn hàng và giá trị COD cần thu), Dispatch/Routing Service (gán tài xế và sinh lộ trình), Driver App/Gateway (nhận sự kiện từ thiết bị tài xế: quét mã, chụp ảnh POD - proof of delivery, xác nhận thu tiền), Hub/Bưu cục Service (ghi nhận tài xế nộp tiền mặt về điểm trung chuyển), và COD Ledger Service (sổ cái COD, nơi chạy batch đối soát). Giao tiếp giữa Order Service và Dispatch là đồng bộ qua REST khi tạo đơn, nhưng cập nhật trạng thái từ hiện trường (tracking event) là bất đồng bộ qua message queue (Kafka) để chịu được tải cao giờ cao điểm và cho phép tài xế gửi sự kiện ngay cả khi mất kết nối tạm thời (retry với offline queue trên app).

Điểm khó khi kiểm thử

• Tính bất đồng bộ: trạng thái đơn có thể chưa cập nhật ngay sau khi tài xế bấm giao xong, cần chờ/poll
• Đồng thời: nhiều sự kiện webhook cho cùng 1 đơn có thể đến gần như đồng thời, gây race condition
• Thiết bị tài xế offline: sự kiện gửi trễ/gửi lại (retry) có thể gây trùng lặp
• Tiền mặt vật lý: hệ thống chỉ ghi nhận số liệu, không thể tự xác minh tiền mặt thật — phải dựa vào đối soát chéo nhiều nguồn

3. Mô hình dữ liệu & bất biến nghiệp vụ (oracle)

Thực thể trung tâm là Order với các trường: orderId, codAmount (số tiền cần thu hộ), status (enum theo state machine), driverId, hubId, createdAt, deliveredAt. Thực thể CashCollection ghi nhận mỗi lần tài xế xác nhận thu tiền tại điểm giao: collectionId, orderId, amount, collectedAt, driverId. Thực thể Remittance ghi nhận tài xế nộp tiền về hub: remittanceId, driverId, hubId, totalAmount, orderIds (danh sách đơn được gộp nộp), remittedAt. Cuối cùng, LedgerEntry là bút toán kế toán nội bộ phản ánh dòng tiền COD, luôn đi theo cặp ghi nợ/ghi có để đảm bảo double-entry, giúp phát hiện sai lệch ngay cả khi một phía dữ liệu bị thao túng hoặc lỗi phần mềm.

Bất biến bắt buộc (oracle)