Nhật ký trước và sau chỉnh sửa công cần lưu những gì?

Khi một bản ghi công bị chỉnh sửa, hệ thống cần lưu cả dữ liệu trước và sau thay đổi, người thực hiện, thời điểm, lý do, trạng thái phê duyệt và ảnh hưởng đến số tiền có thể nhận. Nhật ký này giúp doanh nghiệp giải trình sai lệch, duyệt lại đúng phiên bản dữ liệu và đối soát được với giao dịch cùng payroll cuối kỳ.

Vì sao chỉ lưu dữ liệu cuối cùng là chưa đủ?

Nếu một bản ghi công ban đầu là 8 giờ, sau đó được sửa còn 6 giờ, việc chỉ lưu “6 giờ” khiến doanh nghiệp mất toàn bộ bối cảnh.

Khi có khiếu nại, sẽ không trả lời được:

• trước đây hệ thống ghi bao nhiêu giờ;
• ai đã sửa;
• sửa lúc nào;
• lý do là gì;
• người duyệt cũ đã duyệt phiên bản nào;
• số tiền có thể nhận thay đổi bao nhiêu;
• có giao dịch nào đã phát sinh trước khi sửa hay không.

Audit trail chính là phần biến một thay đổi dữ liệu thành một sự kiện có thể kiểm chứng.

Những trường tối thiểu cần lưu

Một bản ghi chỉnh sửa công nên có tối thiểu các nhóm sau.

1. Khóa nhận diện bản ghi

Bao gồm:

• mã người lao động;
• khách hàng/nơi làm việc;
• ngày công;
• ca;
• mã bản ghi;
• kỳ lương.

Khóa phải đủ ổn định để liên kết với giao dịch và payroll.

2. Dữ liệu trước chỉnh sửa

Ví dụ:

• giờ vào;
• giờ ra;
• tổng giờ;
• ca;
• tăng ca;
• trạng thái;
• đơn vị áp dụng;
• trạng thái duyệt.

3. Dữ liệu sau chỉnh sửa

Lưu đúng các trường đã thay đổi để so sánh với bản cũ.

4. Ai thực hiện

Cần biết:

• tài khoản;
• vai trò;
• phạm vi quyền;
• nguồn thao tác.

5. Khi nào thay đổi

Lưu thời gian đủ chính xác để đối chiếu với:

• thời điểm giao dịch;
• thời điểm duyệt;
• thời điểm đồng bộ;
• thời điểm khóa kỳ.

6. Lý do chỉnh sửa

Không nên chỉ cho nhập tự do.

Có thể dùng mã lý do như:

• thiếu giờ vào;
• thiếu giờ ra;
• sai ca;
• tăng ca chưa ghi nhận;
• dữ liệu trùng;
• sai nơi làm việc;
• điều chỉnh theo xác nhận khách hàng.

Sau đó có thêm ghi chú nếu cần.

Nên lưu cả “ai sửa” và “ai duyệt lại”

Người sửa dữ liệu không nhất thiết là người được quyền phê duyệt phiên bản mới.

Nếu hệ thống cho phép một người vừa sửa vừa duyệt lại mọi trường hợp, rủi ro kiểm soát tăng.

Vì vậy audit trail nên tách:

Vai trò	Cần lưu
Người tạo yêu cầu sửa	Ai đề nghị
Người thực hiện sửa	Ai thay dữ liệu
Người duyệt lại	Ai xác nhận phiên bản mới
Người xử lý ngoại lệ	Nếu có chênh lệch tài chính

Phân tách này giúp xác định trách nhiệm khi có sự cố.

Ảnh hưởng tài chính phải được ghi cùng thay đổi

Nếu dữ liệu công liên quan tới Lương Ngày, hệ thống cần biết thay đổi đó tác động ra sao.

Ví dụ:

• trước sửa: 8 giờ;
• sau sửa: 6 giờ;
• giá trị công giảm;
• số tiền có thể nhận giảm;
• đã có giao dịch hay chưa;
• chênh lệch đang chờ xử lý hay không.

Một audit trail chỉ ghi “8 → 6 giờ” nhưng không biết ảnh hưởng tới số tiền sẽ chưa đủ cho Payroll Integrity.

Trường hợp chưa có giao dịch

Nếu công bị sửa trước khi người lao động nhận tiền:

1. bản ghi quay về chờ duyệt;
2. phiên bản mới được xác nhận;
3. số tiền có thể nhận được tính lại;
4. audit trail ghi đầy đủ trước/sau.

Đây là tình huống tương đối đơn giản.

Trường hợp đã có giao dịch

Nếu tiền đã được chi:

• giao dịch cũ phải giữ nguyên;
• công mới vẫn phải được duyệt lại;
• hệ thống tính lại giá trị;
• phần chênh lệch đi vào quy trình đối soát;
• không được xóa giao dịch chỉ vì công thay đổi.

Chính trường hợp này cho thấy audit trail phải nối được với giao dịch, không chỉ với dữ liệu công.

Audit trail cần giữ ở đâu?

Về nguyên tắc hệ thống, audit trail nên:

• nằm trong kho dữ liệu có kiểm soát;
• không cho người dùng thông thường xóa;
• có quyền xem theo vai trò;
• có khả năng tìm theo người lao động, ngày, khách hàng, giao dịch;
• có thời gian hệ thống thống nhất;
• có bản ghi bất biến hoặc cơ chế hạn chế sửa log.

Không nên dùng một file Excel thủ công làm nguồn audit duy nhất cho quy trình có tiền.

Dashboard audit nên hỗ trợ gì?

Đội vận hành nên lọc được:

• công sửa sau khi đã duyệt;
• công sửa sau khi đã phát sinh giao dịch;
• số lần sửa trên cùng bản ghi;
• người sửa;
• lý do;
• thời gian chờ duyệt lại;
• chênh lệch tiền trước/sau;
• bản ghi chưa xử lý xong.

Những bản ghi có tiền đã chi nên được ưu tiên cao hơn.

Audit trail có giúp giảm khiếu nại không?

Có, vì khi người lao động hỏi “vì sao số tiền thay đổi”, đội hỗ trợ có thể kiểm tra:

• ngày nào bị sửa;
• trước đây là gì;
• sau đó là gì;
• ai duyệt lại;
• tác động tới số có thể nhận.

Thay vì trả lời chung chung, doanh nghiệp có bằng chứng cụ thể.

Nhật ký cần hiển thị cho người lao động đến mức nào?

Không nhất thiết hiển thị toàn bộ thông tin nội bộ.

Có thể hiển thị:

• ngày công;
• trạng thái;
• dữ liệu trước/sau ở mức cần thiết;
• lý do thay đổi;
• thời điểm cập nhật;
• kênh phản hồi.

Thông tin nội bộ như tài khoản quản trị hoặc log kỹ thuật có thể giới hạn theo quyền.

Những lỗi thiết kế audit thường gặp

• chỉ giữ dữ liệu cuối;
• cho sửa log;
• không lưu lý do;
• không lưu người duyệt lại;
• không nối với giao dịch;
• dùng tên người thay cho ID ổn định;
• không có timezone thống nhất;
• không lưu thay đổi từ nguồn ngoài như Google Sheet;
• không cảnh báo sửa sau khi đã chi.

Các lỗi này làm việc truy vết khó hơn rất nhiều.

Kết luận

Nhật ký trước/sau là nền tảng của Payroll Integrity vì nó trả lời được dữ liệu đã thay đổi từ gì sang gì, ai làm, vì sao, khi nào và ảnh hưởng tiền ra sao. Khi audit trail nối được công, giao dịch và payroll, doanh nghiệp có thể xử lý sai lệch dựa trên bằng chứng thay vì dựa vào trí nhớ hoặc trao đổi rời rạc.

[TÊN TÁC GIẢ] — [Chức vụ]

Tìm hiểu Lương Ngày cho doanh nghiệp