Audit trail trong EWA cần ghi lại những gì?

Audit trail trong EWA cần đủ để tái hiện toàn bộ hành trình từ dữ liệu lao động đến kết quả tài chính. Hệ thống nên ghi lại ai làm gì, khi nào, dữ liệu trước và sau, phiên bản chính sách, kết quả tính, lý do đủ hoặc không đủ điều kiện, trạng thái giao dịch, bằng chứng đối soát và cách khoản tiền được phản ánh vào payroll.

Audit trail không chỉ là lịch sử sửa công

Audit trail sửa công là một phần quan trọng, nhưng chỉ là một lát cắt.

Một giao dịch EWA còn đi qua:

• hồ sơ người lao động;
• nơi làm việc;
• công;
• duyệt công;
• đơn giá;
• chính sách;
• phép tính số khả dụng;
• điều kiện sử dụng;
• tài khoản nhận;
• yêu cầu giao dịch;
• ngân hàng;
• đối soát;
• payroll.

Mục tiêu là có thể trả lời:

> “Tại sao hệ thống đã đưa ra kết quả này ở thời điểm đó?”

Audit trail cấp hồ sơ người lao động

Cần lưu những thay đổi ảnh hưởng khả năng sử dụng:

• tạo hồ sơ;
• cập nhật định danh;
• thay trạng thái làm việc;
• gắn/bỏ nơi làm;
• thay mã chấm công;
• thay tài khoản nhận;
• thay thiết bị nếu chính sách có kiểm soát thiết bị.

Mỗi sự kiện nên có:

• người/thành phần thực hiện;
• thời gian;
• giá trị trước;
• giá trị sau;
• lý do;
• nguồn.

Không nên chỉ giữ dữ liệu hiện tại.

Audit trail của công và duyệt công

Đây là phần bài 135 đã đi sâu.

Tối thiểu cần lưu:

• công được tạo từ nguồn nào;
• giá trị ban đầu;
• người duyệt;
• thời điểm duyệt;
• dữ liệu bị sửa gì;
• trước/sau;
• ai sửa;
• lý do;
• ai duyệt lại;
• giao dịch nào bị ảnh hưởng.

Điểm quan trọng là phê duyệt phải gắn với phiên bản dữ liệu.

Nếu dữ liệu đã thay đổi, phê duyệt cũ không tự động áp dụng cho phiên bản mới.

Audit trail của chính sách và cấu hình

Một giao dịch hôm nay có thể khác một giao dịch tháng trước dù công giống nhau.

Nguyên nhân có thể là chính sách khác phiên bản.

Vì vậy cần lưu:

• mã chính sách;
• phiên bản;
• ngày hiệu lực;
• phạm vi khách hàng;
• giá trị cấu hình liên quan;
• ai tạo;
• ai phê duyệt;
• khi nào kích hoạt;
• khi nào ngừng áp dụng.

Khi tính hoặc đánh giá điều kiện, hệ thống nên lưu policy version đã dùng.

Nếu chỉ lưu cấu hình hiện tại, vài tháng sau khó tái hiện quyết định cũ.

Audit trail của Earned Wage Engine

Mỗi lần tính quan trọng nên có đủ đầu vào để giải thích kết quả:

• số công đã duyệt;
• đơn giá;
• kỳ;
• số đã nhận;
• phần giữ;
• nguồn dữ liệu;
• thời điểm snapshot;
• kết quả.

Không nhất thiết lưu mọi phép tính UI lặp lại như một sự kiện nặng, nhưng giao dịch tài chính cần có snapshot đầu vào đủ để tái hiện.

Công thức nền tảng:

Số tiền có thể nhận = (số công đã duyệt × đơn giá một ngày công) − số đã nhận trong kỳ − phần giữ lại theo quy định của doanh nghiệp.

Audit trail cần cho biết từng thành phần tại thời điểm quyết định.

Audit trail của Eligibility Engine

Eligibility Engine cần lưu:

• người lao động;
• thời điểm đánh giá;
• số tiền đầu vào;
• phiên bản chính sách;
• các rule quan trọng;
• kết quả;
• mã lý do.

Ví dụ:

• đủ điều kiện;
• chưa đủ công;
• trạng thái xác minh tài khoản chưa hoàn tất;
• khách hàng chưa bật;
• có giao dịch đang chờ;
• vượt phạm vi hiện tại.

Mã lý do giúp đội hỗ trợ giải thích mà không phải đọc code.

Audit trail của giao dịch

Đây là phần quan trọng nhất với dòng tiền.

Một giao dịch nên có:

• transaction ID;
• request ID;
• idempotency key nếu áp dụng;
• người lao động;
• tài khoản nhận đã che phù hợp;
• số tiền;
• thời gian tạo;
• các trạng thái đã đi qua;
• phản hồi ngân hàng;
• mã tham chiếu;
• retry;
• ai can thiệp thủ công;
• kết quả cuối.

Không nên chỉ lưu trạng thái cuối SUCCESS.

Audit trail của trạng thái pending và retry

Nếu giao dịch timeout:

• hệ thống đã gửi lệnh lúc nào;
• phản hồi nào bị thiếu;
• trạng thái chuyển sang pending khi nào;
• ai/tiến trình nào tra soát;
• có retry hay không;
• retry dùng cùng hay khác mã;
• bằng chứng nào kết luận trạng thái cuối.

Đây là nơi audit trail giúp chứng minh hệ thống không “retry mù”.

Audit trail của Reconciliation

Đối soát cần lưu:

• nguồn đối chiếu;
• file/snapshot;
• ngày đối soát;
• khóa ghép;
• giao dịch khớp;
• giao dịch lệch;
• mã ngoại lệ;
• owner;
• hành động xử lý;
• bằng chứng đóng.

Không nên chỉ lưu “reconciled = true”.

Cần biết đối soát với nguồn nào và bằng dữ liệu nào.

Audit trail khi đưa vào payroll

Cuối kỳ cần truy được:

• giao dịch nào thuộc kỳ;
• tổng số đã nhận;
• giao dịch nào bị loại vì thất bại;
• giao dịch pending xử lý ra sao;
• số được đưa vào payroll;
• ai phê duyệt;
• báo cáo cầu nối;
• chênh lệch.

Mục tiêu là khoản đã nhận được phản ánh đúng một lần.

Nên dùng event log hay chỉ lưu cột updated_at?

updated_at chỉ cho biết bản ghi vừa thay đổi khi nào.

Nó không trả lời:

• ai thay đổi;
• trường nào thay đổi;
• trước là gì;
• sau là gì;
• vì sao;
• quyết định nào bị ảnh hưởng.

Vì vậy các sự kiện quan trọng nên có event/audit log riêng.

Có thể vẫn giữ updated_at cho hiệu năng, nhưng không xem nó là audit trail đầy đủ.

Một audit event tối thiểu gồm gì?

Trường	Ý nghĩa
Event ID	Định danh sự kiện
Entity type	Công, policy, giao dịch, payroll...
Entity ID	Bản ghi liên quan
Actor	Người/hệ thống thực hiện
Action	Tạo, sửa, duyệt, gửi, đối soát...
Timestamp	Thời điểm
Before	Giá trị trước nếu có
After	Giá trị sau
Reason code	Lý do
Correlation ID	Nối chuỗi sự kiện
Source	App/API/Sheet/ERP/ngân hàng
Approval	Ai phê duyệt nếu cần

Correlation ID đặc biệt hữu ích để truy một giao dịch qua nhiều hệ thống.

Audit trail cần chống sửa như thế nào?

Về nguyên tắc kiểm soát:

• người dùng nghiệp vụ thông thường không được xóa log;
• quyền đọc log phải phân vai;
• thay đổi log, nếu có, cũng phải để lại dấu vết;
• thời gian hệ thống cần thống nhất;
• thông tin cần bảo vệ phải được che hoặc giới hạn;
• thời gian lưu giữ phải theo chính sách và yêu cầu áp dụng.

Không nên công khai chi tiết hạ tầng bảo mật trong bài công khai.

Audit không có nghĩa lưu mọi thứ vô hạn

Data minimization vẫn quan trọng.

Audit trail cần đủ để chứng minh và vận hành, nhưng không nên nhân bản không cần thiết:

• ảnh CCCD;
• số tài khoản đầy đủ;
• dữ liệu vị trí;
• ảnh khuôn mặt;
• thông tin cá nhân không liên quan.

Có thể lưu reference ID, bản che hoặc hash phù hợp thay vì sao chép thông tin cần bảo vệ vào mọi log.

Ai cần xem audit trail?

Không phải ai cũng được xem toàn bộ.

Có thể phân quyền:

• người lao động: trạng thái và thay đổi liên quan tới mình ở mức phù hợp;
• quản lý khách hàng: công trong phạm vi;
• payroll: dữ liệu đối trừ;
• vận hành: giao dịch và ngoại lệ;
• kỹ thuật: log hệ thống cần thiết;
• kiểm toán/pháp chế: hồ sơ theo thẩm quyền.

Quyền xem log cũng cần được ghi lại nếu thông tin cần bảo vệ.

Audit trail giúp xử lý khiếu nại thế nào?

Khi người lao động hỏi:

> “Tại sao hôm qua tôi thấy 900.000 đồng mà hôm nay còn 600.000 đồng?”

Hệ thống có thể truy:

1. công nào thay đổi;
2. ai sửa;
3. ai duyệt lại;
4. policy version nào;
5. giao dịch nào vừa thành công;
6. số đã nhận thay đổi thế nào;
7. phép tính mới.

Thay vì đoán, đội hỗ trợ có timeline.

KPI chất lượng audit

Có thể theo dõi:

• tỷ lệ sự kiện có actor;
• tỷ lệ có reason code;
• tỷ lệ giao dịch truy được end-to-end;
• số log thiếu correlation ID;
• số chỉnh sửa thủ công không có phê duyệt;
• số ngoại lệ thiếu bằng chứng đóng;
• thời gian truy nguyên sự cố;
• số khiếu nại không tái hiện được.

Audit trail chỉ có giá trị khi được kiểm tra chất lượng.

Kết luận

Audit trail trong EWA phải đủ để tái hiện một quyết định và một dòng tiền từ đầu đến cuối: ai tạo dữ liệu, ai duyệt, chính sách nào được áp dụng, hệ thống tính ra sao, vì sao đủ điều kiện, giao dịch đi qua trạng thái nào, đối soát với nguồn nào và cuối cùng vào payroll thế nào. Khi audit được thiết kế xuyên chuỗi, EWA trở nên giải thích được, kiểm soát được và xử lý sai lệch nhanh hơn.

Tác giả: Đỗ Huy Lê — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

Tư vấn Lương Ngày cho doanh nghiệp: Hotline 0937.022.655 · Email info@nhankiet.vn · Tìm hiểu Lương Ngày cho doanh nghiệp