Dữ liệu phí sàn được cập nhật thế nào

Trả lời nhanh: Dữ liệu phí sàn không nên được cập nhật bằng cách tìm một tỷ lệ mới rồi sửa đè con số cũ. Một bản cập nhật đáng tin phải có nguồn, tỷ lệ hoặc công thức, ngày hiệu lực, phạm vi áp dụng, phiên bản lịch sử, kiểm tra xung đột và trạng thái hiển thị cho người dùng.

Một dòng phí cần nhiều hơn một tỷ lệ

Để một quy tắc phí có thể dùng an toàn, tối thiểu cần biết:

• nền tảng;
• loại phí;
• tỷ lệ hoặc số tiền;
• cơ sở tính;
• mức trần nếu có;
• loại shop;
• ngành hàng;
• chương trình;
• ngày bắt đầu hiệu lực;
• ngày hết hiệu lực nếu có;
• nguồn;
• nhà phát hành;
• ngày kiểm tra nguồn.

Một dòng “phí 5%” không đủ. Nó có thể đúng ở một phạm vi nhưng sai ở phạm vi khác.

Thứ tự nguồn nên ưu tiên

Nguồn chính thức

• Seller Center hoặc Kênh Người Bán;
• thông báo chính thức;
• tài liệu biểu phí;
• hợp đồng hoặc phụ lục;
• hóa đơn, settlement hoặc bảng kê chính thức.

Nguồn bổ trợ

• email chính thức;
• ảnh hoặc PDF chính thức;
• bài tổng hợp từ đơn vị phần mềm bán hàng;
• báo cáo cộng đồng.

Nguồn bổ trợ có thể giúp phát hiện thay đổi, nhưng không nên tự động nâng dữ liệu thành đã xác minh nếu thiếu phạm vi hoặc mâu thuẫn với nguồn chính thức.

Quy trình cập nhật dữ liệu phí

1. Phát hiện tín hiệu thay đổi

Tín hiệu có thể đến từ thông báo sàn, người bán báo chênh lệch, nguồn được cập nhật hoặc hệ thống giám sát phát hiện nội dung khác.

Tín hiệu chỉ mở một việc cần kiểm tra; nó chưa phải quyền sửa dữ liệu công khai.

2. Đọc nguồn và trích xuất phạm vi

Người duyệt cần xác định:

• mức phí mới;
• đã gồm VAT hay chưa;
• ngày hiệu lực;
• ngành hoặc loại shop;
• chương trình bắt buộc hay tùy chọn;
• mức trần;
• ngoại lệ;
• quy tắc cũ bị thay thế.

Nếu nguồn không nói rõ một yếu tố quan trọng, không nên tự suy đoán.

3. So với quy tắc hiện tại

Kiểm tra:

• có chồng lấn ngày không;
• có hai quy tắc cùng specificity không;
• quy tắc mới thay quy tắc cũ hay bổ sung;
• có cần đóng effectiveTo của quy tắc cũ không;
• lịch sử có bị sửa đè không.

Lịch sử cần được giữ để tính đúng theo mốc thời gian cũ và phục vụ audit.

4. Gán mức tin cậy phù hợp

Trong contract hiện tại:

policy_verified

Đủ để công khai calculator phạm vi hẹp khi:

• có nguồn chính thức hoặc nguồn công khai đáng tin;
• tỷ lệ, ngày hiệu lực và phạm vi rõ;
• không có silent fallback hoặc defaultRate;
• thiếu dữ liệu, xung đột hoặc ngoài phạm vi thì fail closed;
• test, npm run validate và giao diện QA pass;
• giao diện hiện nguồn, ngày cập nhật và disclaimer.

Mức này không tuyên bố khớp payout từng đồng.

settlement_verified

Là mức nâng cao, chỉ cần khi muốn tuyên bố:

• khớp chính xác payout;
• khớp số tiền sàn khấu trừ;
• chính xác từng đồng.

Mức này cần reconciliation, cách làm tròn và dữ liệu settlement phù hợp.

5. Cập nhật schema, quy tắc và test

Dữ liệu mới phải đi qua schema. Nếu cấu trúc nguồn yêu cầu field mới, cần cập nhật đồng bộ:

• Zod schema;
• loader;
• resolver;
• engine;
• test;
• giao diện.

Không nên thêm field vào YAML rồi hy vọng hệ thống tự hiểu.

6. Chạy kiểm tra và QA

Cổng code duy nhất là:

npm run validate

Ngoài ra, giao diện cần được kiểm tra:

• desktop và mobile;
• trạng thái chưa tính, lỗi, kết quả, reset;
• overflow;
• console error;
• accessibility cơ bản;
• nhãn nguồn và trạng thái dữ liệu.

7. Công khai với thông tin người dùng cần biết

giao diện nên dùng các nhãn dễ hiểu:

• Theo chính sách công bố
• Ước tính tham khảo
• Bạn tự nhập phí

Không nên đưa thuật ngữ nội bộ ra màn hình nếu người dùng không cần biết.

Khi nào dữ liệu phải bị hạ trạng thái

Cần dừng hoặc cảnh báo khi:

• nguồn bị gỡ hoặc không còn truy cập;
• có tín hiệu chính sách thay đổi;
• quá hạn kiểm tra theo SLA;
• phát hiện xung đột;
• phạm vi không map được;
• payout lệch có hệ thống;
• test hoặc build thất bại;
• không xác định được ngày hiệu lực.

Fail closed có nghĩa là không âm thầm chọn một tỷ lệ gần giống để trả về kết quả.

Hệ thống giám sát phí được phép làm gì

Monitor có thể:

• kiểm tra nguồn;
• phát hiện thay đổi văn bản;
• tạo báo cáo;
• tạo đề xuất;
• ưu tiên nguồn cần người duyệt.

Monitor không được:

• tự sửa YAML công khai;
• tự tăng trạng thái xác minh;
• tự đổi checkedAt;
• tự động gộp thay đổi;
• gọi dữ liệu là realtime.

Với website static cần người duyệt, “realtime” là mô tả sai.

Người bán nên đọc dữ liệu thế nào

Trước khi dùng kết quả, hãy kiểm tra:

1. Nhãn dữ liệu là gì?
2. Nguồn nào?
3. Cập nhật ngày nào?
4. Áp dụng cho sàn, shop, ngành và chương trình nào?
5. Có khoản nào bạn tự nhập không?
6. Kết quả là ước tính chính sách hay đã đối soát settlement?

Dữ liệu được cập nhật theo thông tin công khai vào ngày hiển thị trên công cụ. Biểu phí và chính sách sàn có thể thay đổi bất cứ lúc nào; kết quả chỉ mang tính tham khảo và có thể chênh lệch nhỏ so với thực tế.

Đọc thêm phương pháp tính, trạng thái dữ liệu và vì sao calculator không nên đoán khi dữ liệu chưa đủ.