Eligibility Engine xác định điều kiện và hạn mức ra sao?

Eligibility Engine là lớp kiểm tra điều kiện sử dụng EWA tại thời điểm người lao động tạo yêu cầu. Nó không tạo ra tiền công; thay vào đó, engine nhận kết quả tiền công đã hình thành rồi áp dụng trạng thái hồ sơ, chính sách doanh nghiệp, giới hạn sử dụng và các điều kiện kiểm soát để xác định phạm vi được phép tiếp tục.

Eligibility Engine giải quyết câu hỏi nào?

Trong EWA có hai câu hỏi dễ bị trộn lẫn:

1. Người lao động đã tạo ra bao nhiêu tiền công từ phần việc được duyệt?
2. Tại thời điểm hiện tại, người đó có đủ điều kiện sử dụng và được phép nhận trong phạm vi nào?

Câu hỏi thứ nhất thuộc Earned Wage Engine. Câu hỏi thứ hai thuộc Eligibility Engine.

Việc tách hai lớp giúp hệ thống không nhầm giữa đã tạo ra giá trị lao động và được phép sử dụng một tính năng tài chính.

Một người có thể đã có công được duyệt nhưng chưa hoàn tất điều kiện hồ sơ. Ngược lại, hồ sơ có thể đầy đủ nhưng chưa có phần tiền công đủ điều kiện để nhận.

Sáu nhóm điều kiện thường cần kiểm tra

Một Eligibility Engine tốt nên tổ chức điều kiện thành các nhóm có ý nghĩa nghiệp vụ.

Nhóm kiểm tra	Câu hỏi cần trả lời	Nguồn dữ liệu
Trạng thái người lao động	Hồ sơ đang hoạt động và thuộc phạm vi áp dụng?	HRM/ERP
Công và tiền công	Có phần tiền công đã hình thành?	Earned Wage Engine
Chính sách doanh nghiệp	Nơi làm việc đã được bật chính sách?	Policy/configuration
Định danh & tài khoản	Hồ sơ nhận tiền đã xác minh?	Identity/account
Giới hạn sử dụng	Yêu cầu hiện tại có nằm trong phạm vi?	Policy + transaction ledger
Trạng thái hệ thống	Có điều kiện buộc dừng/giữ chờ?	Transaction/monitoring

Điều quan trọng là mỗi điều kiện phải có nguồn dữ liệu và chủ sở hữu rõ ràng.

Nếu một quy tắc dựa trên dữ liệu không có nguồn sự thật, hệ thống rất khó giải thích khi người lao động bị từ chối hoặc bị giới hạn.

Hạn mức là kết quả của chính sách, không phải tiền công

Trong EWA, “hạn mức” không nên được hiểu là một khoản tiền độc lập được cấp sẵn cho người lao động.

Earned Wage Engine trước hết xác định phần tiền công đã hình thành.

Eligibility Engine sau đó có thể áp dụng các quy tắc để thu hẹp phạm vi được phép sử dụng, nhưng không nên tự tạo ra một giá trị lớn hơn phần tiền công đủ điều kiện.

Có thể hình dung:

Giá trị có thể sử dụng ≤ Phần tiền công đã hình thành đủ điều kiện

Với Lương Ngày, phép tính nền tảng của phần tiền công có thể nhận là:

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.

Sau đó, các điều kiện sử dụng khác mới được đánh giá.

Vì sao phải kiểm tra lại tại thời điểm yêu cầu?

Một trạng thái “đủ điều kiện” hiển thị trên ứng dụng có thể đã cũ.

Từ lúc người lao động mở màn hình đến lúc bấm xác nhận, có thể xảy ra:

• công bị sửa;
• một giao dịch khác vừa thành công;
• trạng thái người lao động thay đổi;
• tài khoản không còn ở trạng thái hợp lệ;
• chính sách bước sang phiên bản mới;
• có giao dịch trước đang chờ.

Vì vậy, máy chủ phải đánh giá lại điều kiện tại thời điểm tạo yêu cầu.

Giao diện chỉ nên hiển thị thông tin; quyết định cuối cùng cần dựa trên dữ liệu máy chủ mới nhất.

Eligibility Engine khác Earned Wage Engine như thế nào?

Lớp	Câu hỏi chính	Dữ liệu trọng tâm
Earned Wage Engine	Tiền công đã hình thành là bao nhiêu?	Công, đơn giá, đã nhận, dự trù
Eligibility Engine	Người này hiện có được dùng và trong phạm vi nào?	Hồ sơ, chính sách, giới hạn, tài khoản
Payment Orchestration	Yêu cầu hợp lệ sẽ được xử lý giao dịch thế nào?	Transaction ID, trạng thái, ngân hàng

Tách ba lớp giúp mỗi lớp có trách nhiệm rõ.

Nếu công thay đổi, Earned Wage Engine tính lại. Nếu chính sách thay đổi, Eligibility Engine đánh giá lại. Nếu mạng ngân hàng timeout, Payment Orchestration xử lý trạng thái giao dịch.

Chính sách cần có phiên bản và ngày hiệu lực

Một lỗi thiết kế phổ biến là chỉ lưu “chính sách hiện tại”.

Khi đó, vài tháng sau doanh nghiệp khó trả lời vì sao một giao dịch cũ được phép còn giao dịch tương tự ở thời điểm khác lại không.

Mỗi bộ quy tắc nên có:

• mã phiên bản;
• ngày/giờ hiệu lực;
• phạm vi áp dụng;
• người tạo;
• người phê duyệt;
• lý do thay đổi;
• trạng thái active/inactive.

Khi một yêu cầu được đánh giá, hệ thống nên lưu dấu vết về phiên bản chính sách đã dùng.

Khi nào Eligibility Engine nên dừng?

Nếu dữ liệu quan trọng chưa đủ chắc chắn, engine không nên tự mở quyền.

Ví dụ:

• trạng thái giao dịch trước chưa rõ;
• công nguồn có xung đột;
• tài khoản nhận chưa hợp lệ;
• hồ sơ không còn hoạt động;
• chính sách không xác định được phiên bản;
• hệ thống nguồn không phản hồi theo cách có thể xác minh.

Trong những trường hợp này, thiết kế an toàn là giữ yêu cầu ở trạng thái cần kiểm tra, thay vì tự giả định mọi thứ đều ổn.

Đây là cùng tư duy fail-closed được dùng trong hệ thống xử lý tiền.

Mã lý do quan trọng không kém kết quả

Eligibility Engine không nên chỉ trả về:

• true;
• false;
• một con số.

Nó nên trả được lý do có cấu trúc, ví dụ:

• chưa có công đã duyệt;
• hồ sơ ở trạng thái chưa hoàn tất xác thực;
• khách hàng chưa bật;
• vượt phạm vi cho phép;
• có giao dịch đang chờ;
• cần xác minh lại tài khoản.

Mã lý do giúp:

• giao diện giải thích cho người dùng;
• hỗ trợ tra cứu;
• vận hành phân loại lỗi;
• đo thống kê;
• audit quyết định.

Không cần công khai các chi tiết kỹ thuật nhạy cảm, nhưng người dùng cần biết hướng xử lý.

Doanh nghiệp nên quản trị Eligibility Engine ra sao?

Eligibility Engine nên được xem như một chính sách có thể thực thi, không chỉ là đoạn mã.

Mỗi quy tắc quan trọng nên có:

• chủ sở hữu nghiệp vụ;
• nguồn dữ liệu;
• ngày hiệu lực;
• lý do tồn tại;
• phạm vi;
• cách xử lý ngoại lệ;
• lịch sử thay đổi.

Đội sản phẩm và payroll cần thống nhất ranh giới giữa phần tiền công đã hình thành và phần được phép sử dụng.

Đội vận hành cần biết lý do một yêu cầu bị giữ.

Đội hỗ trợ cần có mã lý do đủ rõ để giải thích mà không phải truy cập cấu hình kỹ thuật nhạy cảm.

KPI nên theo dõi

Có thể theo dõi:

• tỷ lệ đủ điều kiện;
• tỷ lệ bị giữ do thiếu công duyệt;
• tỷ lệ bị giữ do hồ sơ/tài khoản;
• số yêu cầu bị chặn vì giao dịch đang chờ;
• số thay đổi chính sách;
• số khiếu nại về điều kiện;
• tỷ lệ quyết định có mã lý do đầy đủ;
• số ngoại lệ phải xử lý thủ công.

Không nên tối ưu KPI theo hướng “càng nhiều người được phép giao dịch càng tốt”. Mục tiêu là đúng điều kiện, giải thích được và nhất quán.

Kết luận

Eligibility Engine giúp EWA tách rõ hai vấn đề: phần tiền công đã hình thành và quyền sử dụng tại một thời điểm cụ thể. Một engine tốt phải đánh giá lại tại thời điểm yêu cầu, dùng chính sách có phiên bản, trả về mã lý do rõ và dừng khi dữ liệu quan trọng chưa chắc chắn. Nhờ đó, doanh nghiệp có thể thay đổi chính sách mà vẫn giữ Payroll Integrity và khả năng giải thích cho người lao động.

Tác giả: Đỗ Huy Lê — Tổng Giám Đốc, Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.

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