“Tôi còn ngày phép, sao đơn nghỉ vẫn chờ duyệt?” Câu hỏi này thường xuất hiện khi cổng nhân sự dùng một chữ “duyệt” cho cả việc cấp quỹ ngày nghỉ lẫn việc chấp thuận một lần vắng mặt. Nhân viên nhìn thấy số dư và tưởng đã được nghỉ; quản lý lại nghĩ đó chỉ là hạn mức để gửi yêu cầu. Hai bên có thể cùng đọc đúng dữ liệu, nhưng hiểu khác đối tượng mà dữ liệu mô tả.
Quản lý quỹ ngày phép cần tách nguồn thời gian được cấp khỏi yêu cầu sử dụng thời gian ấy. Bài viết đề xuất cách thể hiện ranh giới này trên website hoặc cổng nhân sự: người dùng biết mình có gì, đang xin gì và cần ai quyết định. Đây là hướng dẫn thiết kế quy trình dữ liệu, không xác định quyền lợi nghỉ phép theo pháp luật hay thay thế chính sách nhân sự đã được doanh nghiệp phê duyệt.
Quản lý quỹ ngày phép bắt đầu từ hai câu hỏi khác nhau
Câu thứ nhất là “Nhân viên được cấp bao nhiêu thời gian thuộc loại nghỉ này?”. Câu thứ hai là “Nhân viên có được vắng mặt vào những ngày cụ thể này không?”. Một khoản cấp có thể áp dụng trong nhiều tháng. Một đơn nghỉ lại gắn với ngày bắt đầu, ngày kết thúc, thời lượng và người xin nghỉ. Không nên dùng mã của khoản cấp làm mã của đơn, hoặc đổi trạng thái cả hai bằng một thao tác không giải thích.
Tài liệu Allocations của Odoo 19 phân biệt thời gian cấp ngay với thời gian tích lũy theo kế hoạch. Đây là ví dụ về cách một sản phẩm tổ chức dữ liệu, không phải căn cứ để suy ra doanh nghiệp nào cũng phải cấp cùng số ngày. Với cổng nội bộ, nên giữ riêng hồ sơ khoản cấp, thời hạn hiệu lực và phương thức hình thành quỹ.
Ở phía sử dụng, đơn nghỉ cần trả lời người nào vắng mặt, vào lúc nào và tình trạng xử lý hiện tại. Quản lý đã đồng ý cho nghỉ tuần sau không đồng nghĩa nhân viên đã nghỉ thực tế. Tương tự, nhân viên gửi đề nghị bổ sung quỹ không có nghĩa khoản bổ sung đã có hiệu lực. Những thông báo như “Đã duyệt thành công” nên nói rõ “khoản cấp” hay “đơn nghỉ”, kèm khoảng thời gian liên quan.
Đừng buộc tất cả loại nghỉ đi qua một công thức. Có loại cần khoản cấp trước khi xin; quy trình khác có thể được cấu hình khác. Nhãn trên website cần phản ánh chính sách đang áp dụng cho đúng loại nghỉ, thay vì biến cách xử lý của một loại thành quy tắc chung cho toàn bộ nhân sự.
Một tình huống nhỏ để kiểm tra cách hiển thị số dư
Giả sử một doanh nghiệp thử nghiệm cổng nhân sự với dữ liệu hoàn toàn giả lập: nhân viên Minh được cấp 8 ngày của một loại nghỉ, có đơn 2 ngày trong tháng tới đã được chấp thuận, một đơn 1 ngày đang chờ xử lý và một đề nghị cấp thêm 2 ngày chưa được duyệt. Các con số này chỉ phục vụ phân tích giao diện, không đại diện cho chế độ nghỉ của Onter hoặc khách hàng.
| Hồ sơ | Điều đã biết | Điều chưa thể kết luận |
|---|---|---|
| Khoản cấp 8 ngày | Quỹ đã được cấp theo hồ sơ hiệu lực | Mọi ngày nhân viên chọn đều được nghỉ |
| Đơn nghỉ 2 ngày | Lịch vắng mặt cụ thể đã được chấp thuận | Nhân viên đã nghỉ thực tế |
| Đơn nghỉ 1 ngày | Có yêu cầu đang chờ xử lý | Yêu cầu chắc chắn được duyệt |
| Đề nghị cấp thêm 2 ngày | Nhân viên xin bổ sung quỹ | Quỹ khả dụng đã tăng thêm 2 ngày |
Nếu chỉ hiện “Còn 8 ngày”, người dùng khó biết đơn nghỉ tương lai đã được tính chưa. Nếu hiện “Còn 5 ngày”, họ lại không biết hệ thống đã giữ cả đơn chờ xử lý hay chưa. Thay vì tự chọn một phép trừ cho mọi nơi, nhóm triển khai cần thống nhất rõ số nào là quỹ được cấp, số nào liên quan đến yêu cầu và số nào được phép dùng để gửi đơn mới.
Trong trang My time của Odoo 19, phần tóm tắt phân biệt các chỉ tiêu về cấp, duyệt, kế hoạch và khả dụng. Tài liệu cũng cho biết số khả dụng tính đến các khoản nghỉ đã duyệt và đã lên kế hoạch. Khi thiết kế riêng, nên mô tả cách tính của hệ thống đang dùng, không sao chép tên chỉ tiêu rồi mặc định chúng có cùng ý nghĩa.
Một cách trình bày hữu ích là để số dư đi cùng ngày đối chiếu và liên kết xem chi tiết. Người dùng có thể mở đúng khoản cấp hoặc đúng đơn tạo ra thay đổi. Nếu phần tổng và danh sách chi tiết lấy từ hai thời điểm khác nhau, cần báo trạng thái đang cập nhật; không để một lần tải lại trang khiến người dùng nghĩ quỹ vừa bị trừ hai lần.
Với kế hoạch tích lũy, số dự kiến ở tương lai phải có nhãn dự kiến. Nó không nên đứng cạnh khoản đã cấp dưới cùng một nhãn “Bạn đang có”. Một báo cáo dùng để lập kế hoạch tháng sau có mục đích khác màn hình xác nhận quyền gửi đơn hôm nay.
Ngày gửi đơn không quyết định một mình việc sử dụng quỹ
Một đơn gửi cuối tháng nhưng xin nghỉ đầu tháng sau có ít nhất ba mốc: lúc gửi yêu cầu, lúc người có thẩm quyền quyết định và thời gian vắng mặt. Khoản cấp còn có thời hạn hiệu lực riêng. Nếu chỉ kiểm tra số dư tại lúc bấm gửi, hệ thống có thể bỏ qua chuyện loại quỹ đó có dùng được cho khoảng nghỉ đã chọn hay không.
Nhóm nhân sự cần xác nhận cách xử lý từng trường hợp trước khi xây tự động hóa: khoản cấp hết hạn trước ngày nghỉ, một đơn đi qua ranh giới hai kỳ, hoặc kế hoạch tích lũy chưa tạo đủ quỹ ở thời điểm dự kiến. Đây là các câu hỏi cấu hình cần có câu trả lời của doanh nghiệp; bài viết không đặt ra quy tắc mất phép hay chuyển phép thay họ.
Đơn vị cũng quan trọng như ngày. Khi một loại nghỉ được quản lý theo giờ, không nên tự đổi sang ngày bằng giả định mọi ngày làm việc đều dài tám giờ. Cổng nhân sự cần dùng đơn vị của loại nghỉ và lịch làm việc đã xác minh. Nếu hiển thị giá trị quy đổi, phải cho người xem biết căn cứ, nhất là với ca không đều hoặc yêu cầu nghỉ một phần ngày.
Khi người dùng đổi khoảng nghỉ, hãy đánh giá lại trên phiên bản yêu cầu mới. Việc một người đã đồng ý cho nghỉ thứ Hai không phải bằng chứng họ đồng ý cho nghỉ cả thứ Hai và thứ Ba. Thiết kế nên giữ lịch sử thay đổi để người duyệt nhận ra nội dung cần xét lại, thay vì chỉ thấy một dấu tích cũ nằm trên nội dung mới.
Ai cấp quỹ, ai duyệt lịch, ai chỉ cần biết có người vắng?
Cấp thêm quỹ và sắp xếp vắng mặt có thể do các vai trò khác nhau phụ trách. Người điều phối nhóm cần biết có đủ người làm việc vào một ngày, nhưng không vì thế mặc nhiên được sửa khoản cấp. Nhân sự quản lý quỹ cũng không nhất thiết là người duyệt cuối cho mọi lịch nghỉ. Cần phân quyền theo thao tác và phạm vi nhân viên, không chỉ theo tên chức danh.
Tài liệu Management của Odoo 19 mô tả các luồng phê duyệt phụ thuộc cấu hình loại nghỉ: có thể không cần, cần một hoặc hai bước. Đây là lý do không nên gắn “đã duyệt lần đầu” với “hoàn tất” trong mọi trường hợp. Giao diện phải cho biết còn bước nào và ai có quyền xử lý, theo cấu hình thực tế đã được kiểm tra.
Với thiết kế đề xuất ở đây, lịch chung của nhóm chỉ cần thông tin phục vụ phối hợp: người vắng, khoảng vắng và trạng thái đủ điều kiện hiển thị. Chi tiết hồ sơ cá nhân, lý do nhạy cảm hay tài liệu đính kèm không nên tự động xuất hiện chỉ vì các thành viên cùng xem một lịch. Phạm vi hiển thị cần được kiểm tra bằng tài khoản đúng vai trò.
Cũng cần phân biệt từ chối một đơn với thu hồi một khoản cấp. Thao tác từ chối yêu cầu nghỉ không được vô tình xóa nguồn quỹ. Ngược lại, thay đổi khoản cấp phải cho thấy những yêu cầu liên quan cần xem xét, thay vì âm thầm sửa lịch đã được chấp thuận. Đây là yêu cầu thiết kế quan hệ dữ liệu, không phải khẳng định phần mềm nào mặc định xử lý đầy đủ.
Chốt quy tắc bằng các lần đối chiếu có thể giải thích
Trước khi đưa cổng nhân sự vào sử dụng, hãy cùng người phụ trách kiểm tra lại tình huống của Minh: đề nghị cấp thêm vẫn chờ thì số nào đổi; từ chối đơn một ngày thì hồ sơ nào giữ nguyên; sửa ngày của đơn hai ngày thì có cần duyệt lại không. Kết quả đúng phải giải thích được bằng các hồ sơ cụ thể, không chỉ bằng một tổng số nhìn có vẻ hợp lý.
Thử thêm một đơn ở sát ngày hết hiệu lực và một yêu cầu theo giờ. Đây là cách phát hiện sớm việc hệ thống so ngày gửi thay cho ngày nghỉ, hoặc quy đổi đơn vị sai. Dữ liệu kiểm thử nên giả lập, không lấy hồ sơ thật của nhân viên để minh họa hoặc gửi cho bên triển khai khi không cần thiết.
Sau đó mới nối dữ liệu đã được xác nhận sang lịch ca hoặc công việc liên quan. Một lịch nghỉ đã duyệt vẫn có thể cần đối chiếu khi bảng công ghi nhận làm việc; đó là phạm vi của đối chiếu chấm công, lịch ca và bảng lương. Đừng dùng thao tác đối chiếu này để âm thầm viết lại quỹ phép hoặc quyết định khoản trả cho nhân viên.
Khi trao đổi yêu cầu xây cổng nội bộ, điều đáng bàn không chỉ là có nút xin nghỉ. Hãy mang theo danh sách loại nghỉ, cách hình thành quỹ, vai trò duyệt và vài tình huống ranh giới. Onter có thể tiếp nhận nhu cầu thiết kế website từ những quy trình cụ thể ấy để xác định phạm vi phù hợp. Giá: Liên hệ. Nhận tư vấn & báo giá.
