Workday Payroll: thiết lập nền cho chạy lương

Bốn khối cấu hình quyết định mọi thứ về sau: pay group (ai được trả), period schedule (bao lâu một lần), run category (trả những khoản gì), và quy trình chạy lương. Sai ở đây thì sửa rất đắt — nhiều thứ không đổi được sau khi đã chạy kỳ lương đầu tiên.

Thứ tự dựng

flowchart LR
  T["Bật quốc gia<br/>(Edit Tenant Setup<br/>– Payroll)"] --> PS["PERIOD SCHEDULE<br/>tần suất + ngày trả<br/>(dùng chung với<br/>Time Tracking được)"]
  PS --> RC["RUN CATEGORY<br/>ai được xử lý +<br/>khoản nào chạy"]
  RC --> PG["PAY GROUP<br/>ghép run category ×<br/>period schedule<br/>+ gán nhân viên"]
  PG --> PRG["(tuỳ chọn)<br/>PAY RUN GROUP<br/>chạy nhiều pay group<br/>cùng lúc"]

Pay group — cẩn thận với hai lựa chọn một chiều

Pay group là nhóm được xử lý chung một lần chạy. Hai điều không sửa được sau khi đã chạy lương: quốc gia của pay group (quyết định đồng tiền), và việc pay group đó dùng cho Payroll Interface hay Workday Payroll — sai thì phải lập pay group mới.

Con số nên nhớ: khuyến nghị ≤150.000 người/pay group; mỗi pay group chỉ có một run category loại thường (regular); mỗi nhân viên thuộc một pay group (trừ trường hợp nhiều vị trí hoặc biệt phái). Gán hàng loạt qua EIB (≤500.000 người/lần) — nhưng nhớ: gán pay group không tự đặt kết quả lương sang trạng thái cần tính lại, phải chủ động chạy lại cho cả pay group cũ lẫn mới.

Có thể tự động hoá bằng quy tắc gán pay group (theo công ty, địa điểm…), mỗi pay group một quy tắc active; không quy tắc nào khớp hoặc nhiều quy tắc cùng khớp thì phải chọn tay.

Period schedule — nơi sinh lỗi ngày tháng

Khai kỳ lương: ngày bắt đầu, ngày kết thúc, ngày trả. Có sẵn cơ chế tự dời ngày trả khi rơi vào cuối tuần hoặc ngày lễ (mỗi schedule gắn được một lịch nghỉ lễ). Ba bẫy hay gặp:

Phải có ít nhất một kỳ nằm trước ngày hiệu lực của giao dịch nhân sự/ lương đầu tiên.
Màn hình sửa chỉ hiện tối đa 100 kỳ quanh ngày hiện tại — kỳ ngoài phạm vi phải vào mục sửa bổ sung; và Workday không tự áp thiết lập dời ngày cho toàn bộ kỳ đã sinh.
Đã bắt đầu xử lý lương thì không đổi được ngày trả — phải huỷ kết quả, sửa lịch, rồi tính lại. Muốn đổi hẳn cấu trúc kỳ, Workday khuyến nghị lập pay group mới và chuyển người sang thay vì sửa lịch đang dùng.

Run category — ai được trả và trả gì

Run category định nghĩa trạng thái nhân viên nào được xử lý (đang làm việc, đang nghỉ dài hạn có ảnh hưởng lương, đã nghỉ việc, đã kết thúc vị trí phụ) và khoản nào tự chạy theo từng loại thanh toán (trong kỳ, trả thay thế, trả bổ sung, trả thủ công).

Ba điểm cần biết:

Quy tắc chọn người: cùng dòng là AND, khác dòng là OR; không khai điều kiện nào là xử lý tất cả nhân viên ở trạng thái đó.
Với người đã nghỉ việc hoặc đang nghỉ dài hạn, Workday tự động xử lý thưởng một lần từ Compensation, payroll input một lần, thuế bắt buộc và chênh lệch truy lĩnh — nhưng payroll input định kỳ thì phải khai trong mục dành cho người không active.
Anh và Ireland nên dùng một run category duy nhất — nhiều run category làm sai cách tính thuế luỹ kế.

Lưu ý vận hành: mỗi lần chạy lương chỉ xử lý một run category, nên tách thưởng ra run category riêng đồng nghĩa phiếu lương riêng, lần chuyển tiền riêng. Cấu hình run category không có ngày hiệu lực — khi truy lĩnh, Workday tính lại theo cấu hình hiện tại, kể cả khoản mới thêm sau đó.

Quy trình và tự động hoá

Pay Cycle Event là business process gói cả chu trình: chạy truy lĩnh → soát → tính lương → soát kết quả và kế toán → phê duyệt → chốt → thanh toán, kèm dấu vết ai duyệt bước nào. Không dùng được khi kỳ lương đang chạy dở.

Tính lương liên tục (continuous payroll calculation) cho job chạy mỗi 5 phút, cập nhật kết quả ngay khi có biến động. Giới hạn quan trọng: chỉ xử lý run category thường và chỉ bắt sự kiện của nhân viên — thay đổi cấu hình thì không → vẫn phải chạy tính đầy đủ cuối kỳ. Muốn dừng thì tạm dừng pay group và để job đang chạy kết thúc; hủy job giữa chừng có thể làm hỏng kế toán và các lần tính sau.

Model My Pay (chỉ Canada và Mỹ) cho nhân viên tự mô phỏng “nếu đổi khoản khấu trừ / khai thuế thì lương thực nhận thay đổi ra sao”.

Nạp lịch sử lương khi go-live

Lịch sử lương = các khoản đã trả trước khi dùng Workday, nạp vào để số luỹ kế và báo cáo cuối năm đúng. Nguyên tắc: chỉ nạp phần thực sự cần cho tính lương và báo cáo năm hiện tại.

Trình tự: tạo kỳ lịch sử trong period schedule → nạp dữ liệu (EIB hoặc nhập tay) → chạy tính lịch sử (bỏ qua hạn mức, sinh luỹ kế/số dư) → đối chiếu → chốt theo đúng thứ tự thời gian.

Bốn gotcha đắt nhất:

Không đảo/huỷ được lịch sử đã chốt — chỉ sửa hoặc đưa về 0 bằng khoản chênh lệch.
Nạp trước khi ghi nhận người nghỉ việc hoặc nghỉ dài hạn, và nạp trước lần tính lương đầu tiên (để bắt các khoản còn dư nợ như khoản vay).
Sửa lịch sử ảnh hưởng mọi công thức dùng số dư lịch sử — phải rà lại kết quả hiện tại.
Lịch sử không sinh bút toán kế toán, không sinh thanh toán, không sinh phiếu lương — nhưng có vào số dư, báo cáo thuế và quyết toán cuối năm.

Cuối cùng, đừng bỏ qua Tenant Analyzer — báo cáo đối chiếu cấu hình của bạn với khuyến nghị của Workday, và Pay Cycle Command Center — bảng điều khiển theo dõi tiến độ từng kỳ lương.

Chắt lọc từ Workday Payroll Administrator Guide (Set Up Payroll Processing, Payroll History tr.75–219) — doc.workday.com. Nội dung biên soạn lại phục vụ học tập, không thay thế tài liệu gốc.