Báo cáo phải khớp với DLR, không phải số lượng gửi

Số lượng tin nhắn đã gửi mang lại cảm giác an tâm: API đã chấp nhận tin nhắn, vì vậy tuần làm việc có vẻ thành công. Tuy nhiên, sự an tâm đó sẽ sụp đổ khi chốt sổ tài chính. Báo cáo tính số lượng gửi là thành công sẽ mâu thuẫn với biên nhận DLR, số tiền trừ trong ví cho lưu lượng nhiều phân đoạn và kiểm toán webhook.

IOSOR áp dụng quy tắc nghiêm ngặt: xuất báo cáo luôn tuân theo biên nhận giao hàng (DLR). Trạng thái đã gửi, trong hàng đợi và được chấp nhận gửi chỉ là dấu vết vận hành. Đã giao, thất bại và không xác định mới là các cột mà bộ phận tài chính và sản phẩm sử dụng để chốt số liệu.

Đã gửi là dấu vết vận hành, không phải chỉ số chốt sổ

Chấp nhận gửi chỉ chứng minh rằng hệ thống đã tiếp nhận công việc. Điều đó không chứng minh rằng thiết bị di động đã nhận được SMS. Nếu KPI chính trong bộ báo cáo của bạn là số lượng gửi, bạn sẽ báo cáo thành công vượt quá thực tế mỗi khi tỷ lệ không xác định hoặc thất bại tăng lên. Hãy giữ số lượng gửi làm cột đo sức chứa nếu cần — tuyệt đối không dùng làm chỉ số thay thế cho tin nhắn đã giao. Hãy rèn luyện quy trình chốt sổ chuẩn: mở các cột DLR trước — không xác định, thất bại, đã giao — sau đó mới xem số lượng gửi để đánh giá tổng lưu lượng.

Các cột xuất dữ liệu dựa trên biên nhận DLR

Cấu trúc xuất dữ liệu xác định rõ ràng trạng thái biên nhận. Trạng thái đã giao yêu cầu phải có DLR. Trạng thái thất bại yêu cầu tín hiệu thất bại cuối cùng. Trạng thái không xác định giữ nguyên là không xác định cho đến khi nhận được DLR — đây không phải là trạng thái giao hàng tạm thời. Tuần hóa đơn che giấu trạng thái không xác định vào nhóm thành công sẽ tạo ra tranh cãi về tỷ lệ giao hàng thực tế. Khi phép tính phân đoạn và hóa đơn không khớp nhau, hãy bắt đầu từ các hàng có biên nhận DLR và số lượng phân đoạn thực tế — không dựa trên tổng số gửi nhân với trung bình ước tính.

Đối soát webhook và sổ cái trên cùng biên nhận

Đối soát kiểm toán webhook với dữ liệu xuất sổ cái là cách bạn chứng minh báo cáo phản ánh đúng thực tế. Nhật ký webhook hàng ngày, trạng thái DLR và các dòng nhật ký sổ cái trả trước phải khớp hoàn toàn với nhau. Nếu webhook báo thất bại trong khi báo cáo ghi nhận thành công, báo cáo đó đã sai — hãy sửa lại cấu trúc xuất dữ liệu, không tự ý điều chỉnh số dư ví.

Duy trì quy trình kiểm toán định kỳ: chọn một ngày, so sánh biên nhận webhook, dữ liệu sổ cái và bộ báo cáo theo ID tin nhắn. Các khoảng lệch được chuyển cho bộ phận vận hành; số liệu thành công không căn cứ phải trả về cho người quản lý báo cáo.

Từ chối các tuần hóa đơn dựa trên số lượng gửi

Bất kỳ kỳ chốt sổ nào lập hóa đơn hoặc ghi nhận thành công chỉ dựa trên số lượng gửi đều phải bị chặn. Hãy chỉnh sửa lại bộ báo cáo để tài chính tập trung vào tỷ lệ đã giao và không xác định. Nếu hợp đồng đối tác vẫn ghi chấp nhận gửi API thành công, hãy dịch ngôn ngữ đó thành ghi chú DLR chứ không bóp méo các cột báo cáo.

Các luồng vận hành liên quan

• Tuần hóa đơn DLR: cổ phần chưa biết không được giao
• Đối soát nhật ký Webhook hàng ngày với số dư trả trước
• Tuần hóa đơn SMS: khi toán học phân đoạn và hóa đơn không khớp

Bắt đầu với IOSOR

Mở gói báo cáo tuần này trong bảng điều khiển IOSOR và xác nhận mọi KPI đầu trang dựa trên biên nhận DLR — delivered, failed và unknown — không phải submit hay API accept. Nếu biểu đồ vẫn coi submit là thành công, đổi tên hoặc gỡ trước khi đóng sổ tài chính. Xuất một lần và dùng chung các cột biên nhận cho sản phẩm và tài chính.

Điểm chính IOSOR

Báo cáo đóng theo biên nhận DLR: delivered, failed và unknown — không theo submit. Submit chỉ đo throughput, không phải sự thật giao nhận hay lý lẽ hóa đơn.

Nên: khóa một schema xuất theo trường biên nhận. Không: sản phẩm ăn mừng accept trong khi tài chính cãi failed DLR.