Một người làm nhiều nơi thì dữ liệu công và tiền được tách thế nào?

Khi một người lao động làm tại nhiều khách hàng hoặc địa điểm, hệ thống EWA cần giữ một danh tính người lao động thống nhất nhưng tách dữ liệu nghiệp vụ theo từng nơi làm việc. Công, mã chấm công, đơn giá, trạng thái duyệt, số tiền có thể nhận và giao dịch phải gắn đúng khách hàng/kỳ để không cộng nhầm công nơi A với chính sách hoặc đơn giá nơi B.

Một người nhưng có nhiều ngữ cảnh làm việc

Đây là bài toán phổ biến trong mô hình cung ứng lao động.

Một người có thể:

• làm ở khách hàng A đầu tháng;
• chuyển sang khách hàng B giữa tháng;
• làm nhiều địa điểm;
• có mã chấm công khác nhau ở từng nơi;
• có ca và đơn giá khác nhau;
• được quản lý bởi các nhóm khác nhau.

Nếu hệ thống chỉ có một “hồ sơ người” mà không có lớp ngữ cảnh nơi làm việc, dữ liệu rất dễ bị trộn.

Danh tính chung và dữ liệu theo nơi phải tách thành hai lớp

Có thể hình dung hai lớp.

Lớp 1 — Danh tính người lao động

Dùng để biết đây là cùng một người:

• họ tên;
• CCCD hoặc khóa định danh phù hợp;
• hồ sơ người lao động;
• tài khoản nhận đã xác minh;
• trạng thái chung của người dùng.

Lớp 2 — Quan hệ làm việc theo khách hàng/nơi làm

Mỗi nơi cần có dữ liệu riêng:

• company_id/mã khách hàng;
• mã chấm công;
• ngày hiệu lực;
• ca;
• công;
• đơn giá;
• chính sách;
• người duyệt;
• kỳ payroll.

Danh tính chung không có nghĩa mọi dữ liệu công được gom vào một rổ.

Vì sao mã chấm công phải theo ngữ cảnh khách hàng?

Một người có thể có:

• mã 00125 ở khách hàng A;
• mã EMP778 ở khách hàng B.

Ngược lại, cùng mã 00125 có thể tồn tại ở hai khách hàng khác nhau nhưng thuộc hai người khác nhau.

Vì vậy, khóa nối không nên chỉ là:

mã chấm công

Mà nên có ngữ cảnh:

khách hàng/nơi làm + mã chấm công → hồ sơ người lao động

Trong hệ thống Lương Ngày, CCCD dùng để nhận diện người lao động ở cấp hồ sơ; company_id xác định khách hàng; mã chấm công được quản lý theo khách hàng.

Công phải được tách theo nơi làm

Nếu một người có công ở A và B, mỗi bản ghi cần biết:

• thuộc nơi nào;
• ngày nào;
• ca nào;
• ai có quyền duyệt;
• phiên bản dữ liệu;
• trạng thái hiện tại.

Không nên chỉ lưu:

> “Nguyễn Văn A — 20 công”

mà thiếu phân bổ.

Cần có khả năng trả lời:

> 12 công ở A, 8 công ở B, với dữ liệu và phê duyệt riêng.

Đơn giá cũng phải theo đúng nơi và thời điểm

Một người có thể có đơn giá khác nhau ở các nơi hoặc ở các thời điểm hiệu lực khác nhau.

Do đó, Earned Wage Engine không nên lấy “đơn giá hiện tại của người lao động” rồi nhân cho toàn bộ công.

Nó cần xác định:

người + nơi làm + ngày/ca + chính sách hiệu lực

sau đó mới tính giá trị.

Nếu dùng nhầm đơn giá của B cho công A, số tiền có thể nhận sẽ sai dù tổng số công hoàn toàn đúng.

Số tiền có thể nhận nên tính riêng hay cộng chung?

Về mặt dữ liệu, nên tính riêng từng nguồn trước, sau đó mới tổng hợp nếu chính sách cho phép.

Ví dụ:

• giá trị đủ điều kiện tại A;
• giá trị đủ điều kiện tại B;
• phần đã nhận liên quan;
• khoản giữ theo từng nơi;
• trạng thái từng nơi.

Sau khi mỗi nhánh được tính đúng, hệ thống mới tạo số tổng phù hợp cho người lao động.

Cách này giúp truy vết khi một nơi sửa công mà không làm mất khả năng giải thích phần còn lại.

Công thức phải có ngữ cảnh nơi làm

Nguyên tắc tổng quát:

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.

Trong multi-workplace, phép tính nên được thực hiện theo từng ngữ cảnh trước.

Ví dụ:

Khả dụng A = công A × đơn giá A − phần đã nhận gắn A − dự trù A

Khả dụng B = công B × đơn giá B − phần đã nhận gắn B − dự trù B

Sau đó Eligibility Engine mới quyết định tổng phạm vi có thể sử dụng theo chính sách.

Giao dịch cần biết tiền đến từ nguồn công nào?

Đây là điểm quan trọng để quyết toán.

Nếu người lao động nhận 500.000 đồng nhưng hệ thống chỉ biết:

> “đã nhận 500.000”

thì cuối kỳ sẽ khó biết khoản đó cần đối trừ ở payroll nào nếu A và B có kỳ hoặc đơn vị quyết toán khác nhau.

Hệ thống nên có khả năng gắn giao dịch với:

• kỳ;
• nơi làm;
• phần công/giá trị đã bao phủ;
• số đã nhận lũy kế.

Nếu một giao dịch tổng hợp từ nhiều nơi, cần có bảng phân bổ nội bộ rõ ràng.

Cách “tách trước, cộng sau” giúp giảm lỗi.

Khi người lao động chuyển từ nơi A sang B giữa kỳ

Cần có ngày hiệu lực rõ.

Ví dụ:

• A có hiệu lực đến 15/9;
• B có hiệu lực từ 16/9.

Hệ thống phải ngăn:

• công ngày 17/9 bị gắn A;
• mã chấm công cũ tiếp tục nhận dữ liệu;
• đơn giá A áp cho B;
• người duyệt A duyệt công B.

Chuyển nơi làm nên là một sự kiện có audit trail.

Nếu một người cùng lúc làm hai nơi thì sao?

Không nên giả định một người chỉ có một nơi active.

Mô hình dữ liệu nên cho phép nhiều assignment đồng thời nếu nghiệp vụ thực tế có.

Mỗi assignment cần:

• phạm vi ngày;
• trạng thái;
• nơi làm;
• mã chấm công;
• lịch/ca;
• chính sách;
• nguồn payroll.

Việc người dùng có được nhận tổng hợp hay tách giao dịch là quyết định sản phẩm/chính sách, nhưng dữ liệu gốc phải vẫn tách.

Duyệt công được phân quyền thế nào?

Người duyệt tại A chỉ nên xem và duyệt công của A.

Người duyệt B không nên:

• xem công chi tiết của A nếu không có quyền;
• sửa công A;
• duyệt thay A;
• xem giao dịch không thuộc phạm vi nếu không cần thiết.

Phân quyền theo nơi làm giúp giảm lỗi và bảo vệ dữ liệu.

Nếu công ở A bị sửa sau khi đã nhận tiền

Hệ thống cần:

1. giữ nguyên lịch sử giao dịch;
2. đưa bản ghi A về trạng thái cần duyệt lại;
3. không làm thay đổi công B nếu không liên quan;
4. tính lại riêng A;
5. xác định chênh lệch;
6. đối soát đúng payroll A/kỳ liên quan.

Đây là lợi ích trực tiếp của việc tách dữ liệu từ đầu.

Đối soát cuối kỳ cần tách thế nào?

Báo cáo cầu nối nên có ít nhất:

Trường	Ý nghĩa
Người lao động	Danh tính chung
Khách hàng/nơi làm	Nguồn công
Kỳ lương	Phạm vi quyết toán
Công đã duyệt	Dữ liệu đầu vào
Giá trị công	Giá trị theo nơi
Tổng đã nhận phân bổ	Phần đã chi
Chênh lệch	Ngoại lệ
Payroll đích	Nơi quyết toán

Nếu một giao dịch đã được phân bổ qua hai nơi, tổng các dòng phân bổ phải bằng giao dịch gốc.

Những lỗi multi-workplace thường gặp

• dùng một mã chấm công cho mọi nơi;
• trộn công của hai khách hàng;
• dùng sai đơn giá;
• người duyệt thấy chéo dữ liệu;
• chuyển nơi nhưng mã cũ vẫn active;
• giao dịch không gắn kỳ/nơi;
• payroll không biết khoản EWA thuộc khách hàng nào;
• cộng trùng khi cùng ngày xuất hiện ở hai nguồn;
• xóa assignment cũ thay vì đóng ngày hiệu lực.

Các lỗi này có thể tạo sai tiền dù từng hệ thống riêng lẻ đều “chạy bình thường”.

KPI nên theo dõi

Doanh nghiệp có thể theo dõi:

• số người có nhiều assignment;
• số mã chấm công chưa khớp;
• số công bị gắn sai nơi;
• số giao dịch thiếu phân bổ;
• số chênh lệch do chuyển nơi;
• tỷ lệ assignment không có ngày hiệu lực;
• số trường hợp đơn giá sai nguồn;
• số khiếu nại multi-workplace.

Các chỉ số giúp phát hiện vấn đề ở mô hình dữ liệu, không chỉ ở từng giao dịch.

Kết luận

Khi một người làm nhiều nơi, kiến trúc tốt phải giữ một danh tính chung nhưng nhiều assignment tách biệt. Công, mã chấm công, đơn giá, duyệt, số khả dụng và payroll cần gắn đúng nơi làm và thời điểm hiệu lực. Nguyên tắc “tách trước, tính đúng, rồi mới tổng hợp” giúp EWA tránh cộng nhầm công, dùng sai chính sách và đối trừ sai kỳ.

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