Thiết kế hệ thống yêu cầu nghỉ phép: chính sách và phê duyệt rõ ràng

Những gì thường hỏng trong quy trình nghỉ phép

Mọi người mong đợi quy trình yêu cầu nghỉ giống như đặt lịch họp: chọn ngày, thấy số dư, nhận câu trả lời rõ ràng có/không, và sự kiện xuất hiện ở mọi nơi cần thiết. Khi không vậy, các đội chuyển sang “nhắn tin thôi”, và hệ thống trở thành nơi lưu trữ thay vì công cụ đáng tin cậy.

Yêu cầu thường bị kẹt ở khâu chuyển giao: chuỗi email nhỡ mất quản lý đúng, một bảng tính không ai cập nhật, hoặc phê duyệt qua chat mà khó kiểm tra sau này. Nhân viên nghĩ họ đã được chấp thuận, quản lý nghĩ HR sẽ xử lý, và HR chỉ phát hiện ra sự sai lệch khi chốt lương.

Mục tiêu thực sự của thiết kế hệ thống yêu cầu nghỉ phép nghe có vẻ nhàm nhưng quan trọng: số dư chính xác, phê duyệt rõ ràng và một nguồn dữ liệu duy nhất. Nếu số dư đúng nhưng phê duyệt không rõ ràng, quản lý sẽ tiếp tục hỏi “Tôi đã phê duyệt chưa?” Nếu phê duyệt đầy đủ nhưng lịch sai, đội vẫn bị trùng lịch.

Có bốn nhóm phụ thuộc vào cùng một luồng công việc, nhưng vì những lý do khác nhau:

• Nhân viên: gửi yêu cầu nhanh, trạng thái tức thì và tin rằng yêu cầu được ghi lại
• Quản lý: nhận đúng yêu cầu, với đủ bối cảnh để ra quyết định
• HR/payroll: chính sách được áp dụng nhất quán và số dư phù hợp với quy tắc trả lương
• Doanh nghiệp: nhìn thấy người nghỉ trong đội mà không lộ thông tin nhạy cảm

Một “luồng đọc được” nghĩa là bạn có thể nhìn vào các bước và giải thích bằng ngôn ngữ đơn giản: điều gì kích hoạt yêu cầu, ai phê duyệt, chuyện gì xảy ra khi từ chối, và gì được ghi lại (số dư, trạng thái, lịch). Nếu bạn không giải thích được nhanh, người ta sẽ né nó.

Các công cụ như AppMaster có thể giúp bằng cách giữ logic trực quan và tập trung, để thay đổi chính sách không biến thành mê cung email và ngoại lệ.

Dữ liệu cơ bản bạn cần (không làm quá)

Một công cụ nghỉ phép tốt chủ yếu là một tập bản ghi gọn và vài quan hệ rõ ràng. Nếu làm đúng phần cơ bản, phần còn lại của thiết kế hệ thống yêu cầu nghỉ phép vẫn đọc được, ngay cả khi chính sách và phê duyệt sau này phức tạp hơn.

Bắt đầu với một tập nhỏ các đối tượng cốt lõi mà bạn có thể giải thích trong một phút:

• Employee: người yêu cầu nghỉ (và người phê duyệt họ).
• TimeOffRequest: yêu cầu thực tế (ngày, loại, trạng thái).
• Policy: quy tắc cho từng loại nghỉ (PTO, ốm, không lương).
• Balance: số dư hiện có của nhân viên theo từng policy.
• Approval: quyết định và bình luận gắn với yêu cầu.

Với các yêu cầu, các trường ngăn đau đầu thực tế không cần cao siêu. Chúng cụ thể. Lưu ngày bắt đầu và kết thúc cùng thời gian nếu cần, có phải nửa ngày hay không, và múi giờ của nhân viên tại thời điểm gửi. Thêm lý do ngắn, và cho phép đính kèm nếu quy trình HR yêu cầu bằng chứng (ví dụ, giấy xác nhận bác sĩ). Để đính kèm là tùy chọn để không chặn PTO bình thường.

Trạng thái nên ít và dự đoán được: draft (lưu nháp), submitted, approved, rejected, canceled. Tránh các trạng thái thừa như “pending HR” trừ khi thực sự cần.

Đừng bỏ qua nhật ký kiểm toán. Ngay cả một “ai thay đổi gì và khi nào” tối thiểu cũng cứu bạn trong tranh chấp. Ít nhất, ghi lại submit, approve, reject, cancel và bất kỳ chỉnh sửa ngày nào.

Với đội, location và phòng ban, xử lý chúng là dữ liệu tham chiếu riêng. Liên kết nhân viên tới các nhóm này, và liên kết chính sách tới nhóm áp dụng. Khi ai đó chuyển văn phòng, bạn cập nhật một bản ghi nhân viên, không phải mọi chính sách.

Nếu bạn xây trong AppMaster, giữ mỗi đối tượng đơn giản trước, rồi thêm kiểm tra và bước luồng công việc khi dữ liệu ổn định.

Quy tắc chính sách: giữ rõ ràng và có thể kiểm tra

Chính sách tốt thường nhàm theo cách có chủ ý. Mọi người nên dự đoán kết quả trước khi bấm Submit. Trong thiết kế hệ thống yêu cầu nghỉ phép, cách nhanh nhất để mất lòng tin là cùng một yêu cầu được chấp thuận tuần này nhưng bị từ chối tuần sau.

Bắt đầu bằng cách đặt tên loại nghỉ và viết một câu mô tả rõ ràng cho mỗi loại. Vacation/PTO là thời gian nghỉ có kế hoạch. Nghỉ ốm là thời gian không lên kế hoạch liên quan sức khỏe. Nghỉ không lương là không được trả lương. Nghỉ thai sản thường có ngày và giấy tờ đặc biệt. Comp time là giờ cộng thêm được quy đổi và tiêu như PTO.

Quy tắc đủ điều kiện nên đọc như checklist, không phải văn bản pháp lý. Viết rõ: ai được dùng (toàn thời, bán thời, nhà thầu), khi bắt đầu (sau thử việc, sau X ngày), và có dựa vào thâm niên không. Nếu có ngoại lệ, viết ngoại lệ như quy tắc riêng, không là chú thích.

Quy tắc gửi yêu cầu là nơi thường gây nhầm lẫn. Hãy cụ thể về thời gian báo trước, ngày cấm, và khối thời gian nhỏ nhất. Ví dụ: “Yêu cầu nghỉ phép phải nộp trước 5 ngày làm việc, trừ trường hợp khẩn cấp được HR duyệt” là có thể kiểm tra. “Nộp sớm” thì không.

Quy tắc chuyển sang năm sau và hết hạn nên vừa đủ trong một câu. Ví dụ: “Tối đa 40 giờ được chuyển sang năm sau và hết hạn vào 31/3.” Nếu cần câu thứ hai, đó là dấu hiệu chính sách quá phức tạp.

Cách giữ văn bản chính sách và logic quy tắc đồng bộ:

• Gán mỗi quy tắc một ID ngắn (như PTO-NOTICE-5D)
• Lưu văn bản ngôn ngữ thường bên cạnh cấu hình quy tắc
• Thêm 2–3 trường hợp mẫu cho mỗi quy tắc (duyệt hoặc từ chối) như bài kiểm tra
• Thay đổi văn bản chính sách cùng lúc với thay đổi cấu hình (và ngược lại)

Ví dụ: Một nhân viên trong thời gian thử việc yêu cầu 2 giờ PTO cho ngày mai. Hệ thống nên chặn vì hai lý do dễ đọc: “PTO starts after 60 days” và “PTO needs 5 business days notice.” Nếu xây trong AppMaster, giữ những thông báo này gần các node quy tắc để cập nhật không bị lệch theo thời gian.

Toán học tích lũy: những mẫu gây nhầm lẫn

Tích lũy là nơi thiết kế hệ thống nghỉ phép thường rối, vì nhiều quy tắc nhỏ cộng lại. Mục tiêu không phải toán cao siêu, mà là kết quả dự đoán được khớp với kỳ vọng HR và nhân viên khi họ kiểm tra số dư.

Một nhầm lẫn phổ biến là trộn các kiểu tích lũy. Một số công ty cộng giờ mỗi kỳ trả lương, có công ty hàng tháng, có nơi tính theo giờ làm việc, và có nơi cấp toàn bộ số ngày hàng năm vào một ngày cố định. Vấn đề phát sinh khi bạn chỉ lưu “số dư” mà quên “cách nó được kiếm.” Giữ một bản ghi rõ ràng của các sự kiện: grant, accrue, adjustment và usage.

Proration (tính tỷ lệ) là bẫy khác. Người mới vào làm giữa tháng hoặc chuyển từ bán thời sang toàn thời không nên cần bảng tính thủ công. Chọn một quy tắc và duy trì nó. Ví dụ: tính tỷ lệ theo số ngày trong kỳ hoặc theo giờ lên lịch. Dù chọn gì, viết rõ bằng lời và mã hóa cùng cách đó ở tất cả nơi.

Giới hạn và số dư âm gây ra các vé “trông sai”. Nếu cho phép chuyển sang năm sau tới một mức cap, áp cap tại thời điểm cụ thể (cuối năm, cuối kỳ tích lũy hoặc sau mỗi lần tích lũy). Nếu cho phép số dư âm, định nghĩa giới hạn và chuyện gì xảy ra khi chấm dứt hợp đồng.

Quy tắc làm tròn tạo trôi nhỏ. Chọn một mức làm tròn (phút, 15 phút, nửa ngày) và áp nhất quán cho cả tích lũy và sử dụng. Nếu bạn tích lũy theo phút nhưng yêu cầu theo nửa ngày, nhân viên sẽ luôn cảm thấy hệ thống sai.

Yêu cầu và sửa lỗi ghi ngày trước cần nhật ký. Nếu ai đó gửi yêu cầu cho tuần trước, hệ thống nên tính lại từ ngày yêu cầu trở đi và ghi lại thay đổi.

Một checklist đơn giản ngắn ngừa hầu hết tranh chấp:

• Lưu thay đổi số dư như các giao dịch có ngày, không chỉ một số duy nhất
• Tính lại từ ngày có hiệu lực khi input chính sách thay đổi
• Áp cap và làm tròn trong một hàm dùng chung
• Giữ điều chỉnh thủ công tách biệt khỏi logic tích lũy
• Luôn hiển thị “tính tới ngày” cho mọi số dư hiển thị

Trong AppMaster, điều này thường ánh ra thành một bảng Transactions cộng một quy trình nhỏ tái tính số dư khi yêu cầu được duyệt hoặc sửa.

Phê duyệt của quản lý: định tuyến đơn giản mà vẫn bao phủ trường hợp cạnh

Luồng phê duyệt quản lý nên trả lời một câu hỏi: ai có thể nói “đồng ý” một cách tự tin? Nếu bạn cố mô hình hóa mọi chi tiết sơ đồ tổ chức, hệ thống trở nên khó đọc và càng khó sửa.

Bắt đầu với quy tắc mặc định: quản lý trực tiếp của nhân viên phê duyệt. Rồi chỉ thêm ngoại lệ khi thực sự ảnh hưởng rủi ro hoặc trách nhiệm. Giữ thứ tự quy tắc rõ ràng, để bạn có thể giải thích kết quả mà không cần mò qua cài đặt.

Phê duyệt một bước so với nhiều bước

Hầu hết đội dùng bước phê duyệt đơn cho PTO tiêu chuẩn. Thêm bước chỉ khi yêu cầu ảnh hưởng tới payroll, tuân thủ, hoặc coverage giữa các đội.

Mẫu phổ biến dễ đọc:

• Một bước: Quản lý phê duyệt cho PTO và nghỉ không lương.
• Hai bước: Quản lý rồi HR cho loại nghỉ cần giấy tờ hoặc kiểm tra chính sách.
• Người phê duyệt thứ hai: Thêm trưởng bộ phận chỉ khi nghỉ ảnh hưởng tới coverage chung (ví dụ, ca trực).
• Auto-approve: Các yêu cầu rủi ro thấp, như 1–2 giờ cho hẹn bác sĩ, hoặc thời gian đã được lên lịch trước.
• Không có quản lý: HR duyệt cho nhà thầu hoặc vai trò không có quản lý rõ ràng.

Ủy quyền, từ chối và gửi lại

Phê duyệt hỏng khi người phê duyệt vắng. Hiện thực ủy quyền như quy tắc chính, không phải giải pháp thủ công. Nếu quản lý được đánh dấu vắng, chuyển đến đại diện; nếu không có đại diện, chuyển đến quản lý của người đó (hoặc HR làm phương án dự phòng). Luôn ghi rõ quy tắc nào chọn người phê duyệt.

Từ chối và chỉnh sửa nơi hệ thống thường rối. Giữ đơn giản: từ chối đóng yêu cầu với lý do bắt buộc. Nếu nhân viên chỉnh sửa ngày hoặc loại nghỉ, coi đó là gửi lại và chạy lại quy tắc định tuyến từ đầu. Điều này ngăn “nửa được phê duyệt” khi yêu cầu đã thay đổi so với những gì đã được phê duyệt.

Ví dụ thực tế: Alex yêu cầu 3 ngày nghỉ ốm. Hệ thống chuyển tới quản lý, nhưng vì đây là loại nghỉ cần kiểm soát chính sách, HR sẽ có bước thứ hai chỉ sau khi quản lý duyệt. Nếu quản lý vắng, đại diện phê duyệt và nhật ký kiểm toán cho thấy lý do.

Nếu xây trong AppMaster, giữ logic định tuyến trong một quy trình trực quan với tập quy tắc nhỏ theo thứ tự rõ ràng, để ai cũng có thể đọc và bảo trì sau này.

Quy tắc xác thực trước khi cho phép gửi

Xác thực tốt giữ cho hệ thống đọc được vì ngăn các trường hợp đặc biệt lọt vào phê duyệt. Nhắm tới các quy tắc dễ giải thích và dễ kiểm tra.

Bắt đầu với quy tắc đặt lịch. Kiểm tra chồng lấp nên phát hiện xung đột với nghỉ đã duyệt và các yêu cầu đang chờ. Hãy rõ về nửa ngày: lưu ngày cộng đơn vị đơn giản như AM, PM hoặc giờ để nửa ngày không bị làm tròn thành nguyên ngày vô ý. Đồng thời quyết định xử lý cuối tuần và ngày lễ: chặn chúng hoặc cho phép nhưng không tính vào tổng ngày.

Kiểm tra số dư phức tạp hơn vẻ bề ngoài. Nhiều đội kiểm tra số dư khi gửi (để tránh gửi tràn) và kiểm tra lại khi phê duyệt (vì tích lũy hoặc phê duyệt khác có thể thay đổi số dư). Nếu làm cả hai, cho người dùng biết điểm nào bị lỗi.

Một tập xác thực sạch sẽ che phủ hầu hết trường hợp:

• Ngày hợp lệ (bắt đầu trước kết thúc, cùng múi giờ, không thiếu chọn nửa ngày)
• Không trùng với nghỉ đã có (bao gồm nửa ngày)
• Số ngày loại trừ cuối tuần và ngày lễ (theo chính sách)
• Đính kèm bắt buộc có nếu loại nghỉ yêu cầu (ví dụ giấy nghỉ ốm)
• Số dư đủ (kiểm tra khi gửi và khi duyệt)

Kiểm tra coverage đội hữu ích nhưng tránh chặn cứng trừ khi cần. Mặc định tốt hơn là cảnh báo cho quản lý quyết định. Ví dụ: “Đã có hai người trong đội nghỉ ngày đó. Vẫn gửi?”

Làm thông báo lỗi công bằng và có thể sửa. Nói rõ người dùng bị lỗi gì, ở đâu và cách sửa. Ví dụ: “Yêu cầu của bạn chồng với PTO đã được duyệt vào 12 Tháng 3 (PM). Chọn thời gian khác hoặc sửa yêu cầu hiện có.”

Nếu xây trong AppMaster, giữ các xác thực gần form yêu cầu và tái sử dụng cùng kiểm tra trong bước phê duyệt để quy tắc không bị lệch theo thời gian.

Từng bước: luồng đọc được bạn có thể xây và bảo trì

Một hệ thống yêu cầu nghỉ phép tốt cảm giác nhàm nhưng theo nghĩa tốt: mọi yêu cầu theo cùng một đường đi, và mỗi quyết định có một lý do rõ ràng. Cách đơn giản nhất giữ nó đọc được là tách dữ liệu chính sách (quy tắc là gì) khỏi logic luồng công việc (chuyện gì xảy ra khi ai đó bấm Submit).

Đây là trình tự giữ đơn giản ngay cả khi thêm nhiều loại nghỉ sau:

• Đặt mọi loại nghỉ và quy tắc tại một chỗ (tên, đủ điều kiện, chuyển dư, ngày cấm). Nếu quy tắc không viết ở đây, nó không nên tồn tại ở đâu khác.
• Mô hình số dư như một dòng thời gian, không phải một con số duy nhất. Lưu opening balance, earned (accrual), used và adjustments để giải thích số dư bất kỳ ngày nào.
• Xây form yêu cầu với các kiểm tra sớm. Xác thực ngày, nửa ngày, chồng lấp, thời gian báo trước và “đủ số dư trước ngày bắt đầu” trước khi bắt đầu phê duyệt.
• Định tuyến phê duyệt dùng tập vai trò nhỏ (nhân viên, quản lý trực tiếp, HR). Thêm ngoại lệ dưới dạng dữ liệu (ví dụ “cần HR nếu 10+ ngày”) thay vì mã cứng các trường hợp đặc biệt.
• Tạo sự kiện lịch chỉ sau khi duyệt, và coi chúng như bản sao đồng bộ có thể cập nhật hoặc hủy khi yêu cầu thay đổi.

Giữ luồng đọc được bằng cách ghi mỗi quyết định bằng ngôn ngữ thường (ví dụ: “Rejected: chồng với nghỉ đã duyệt”). Nếu dùng công cụ trực quan như Business Process Editor của AppMaster, gắn nhãn các bước như cách người thật sẽ đọc.

Trước khi ra mắt, thử với các kịch bản thực: yêu cầu ghi ngày trước, quản lý vắng, thay đổi chính sách giữa năm, và chỉnh sửa sau khi duyệt. Nếu kết quả làm HR ngạc nhiên, quy tắc chưa đủ rõ.

Tích hợp lịch giữ chính xác theo thời gian

Lịch nên trả lời nhanh một câu: ai vắng và khi nào. Đừng biến sự kiện lịch thành toàn bộ bản ghi yêu cầu. Đưa chỉ những gì giúp lên lịch, và giữ phần còn lại trong hệ thống HR.

Với nội dung sự kiện, giữ nhất quán. Mặc định tốt là tiêu đề ngắn như “Out of office - Alex Kim” kèm loại nghỉ nếu cần (“PTO”, “Sick”). Giữ chi tiết tối thiểu để bảo mật. Nhiều đội thích hiện trạng sự kiện là “Busy” và lưu lý do, số dư, ghi chú chỉ trong yêu cầu.

Xem sự kiện lịch như bản sao, không phải nguồn

Mỗi yêu cầu cần một ID nội bộ ổn định, và mỗi sự kiện lịch nên lưu ID đó (ví dụ trong trường tuỳ chỉnh hoặc mô tả). Như vậy bạn có thể tạo, cập nhật và xóa đúng sự kiện khi yêu cầu thay đổi.

Xử lý trạng thái là nơi hệ thống dễ lệch. Quyết trước là có hiển thị các yêu cầu tạm thời hay không. Nếu hiển thị, làm khác biệt rõ (ví dụ tiền tố “Pending” và cài đặt hiển thị khác). Khi duyệt, cập nhật cùng sự kiện thay vì tạo mới. Nếu hủy hoặc từ chối sau khi đã hiển thị, xóa sự kiện để lịch không sai lệch.

Múi giờ và các ngày “khó chịu”

Múi giờ gây rắc rối nhất với nghỉ cả ngày và nửa ngày. Lưu start và end dưới dạng timestamp chính xác theo múi giờ địa phương của nhân viên, và cũng lưu múi giờ đó trên yêu cầu.

Dùng all-day events chỉ cho nghỉ nguyên ngày. Với nửa ngày, tạo sự kiện có thời gian cụ thể (ví dụ 13:00–17:00) để đồng nghiệp ở múi giờ khác thấy chồng lấp đúng.

• Ngày đầy: sự kiện cả ngày theo múi giờ nhân viên
• Nửa ngày: sự kiện có giờ bắt đầu và kết thúc
• Nhiều ngày: sự kiện cả ngày ổn, nhưng kiểm tra quy tắc ngày kết thúc (bao gồm hay không)

Nếu đồng bộ lịch thất bại, đừng giấu. Hàng đợi job, thử lại có lùi dần, và hiển thị trạng thái “Lịch chưa cập nhật” với hành động “thử đồng bộ lại” thủ công. Trong các công cụ như AppMaster, đây thường là một background process cộng màn hình admin liệt kê các lần sync lỗi để HR sửa mà không cần chỉnh yêu cầu.

Lỗi phổ biến và cách tránh

Hầu hết thất bại trong thiết kế hệ thống nghỉ phép xảy ra khi các quy tắc âm thầm phình ra theo thời gian. Hệ thống vẫn “chạy”, nhưng chẳng ai tin số dư nữa, và mọi trường hợp lạ thành vé hỗ trợ.

Lỗi 1: Logic tích lũy bị chôn trong ngoại lệ

Nếu tích lũy bị chia thành nhiều ngoại lệ (nhân viên mới, chuyển dư, nghỉ không lương, bán thời), người dùng không thể dự đoán số dư.

Giữ một mô hình tích lũy rõ ràng cho mỗi loại nghỉ, rồi thêm ngoại lệ như các quy tắc đặt tên và kiểm tra được. Viết vài mẫu nhân viên và số dư dự kiến cho ngày cụ thể, và kiểm tra lại khi chính sách thay đổi.

Lỗi 2: Luồng phê duyệt phân nhánh mãi

Phê duyệt phân nhánh vô tận trở nên không thể test, và quản lý không biết tại sao yêu cầu được gửi cho người khác.

Mẫu an toàn là:

• Một người phê duyệt mặc định (thường là quản lý trực tiếp)
• Một người phê duyệt bổ sung tùy chọn (HR hoặc trưởng bộ phận) dựa trên điều kiện đơn giản
• Một fallback rõ ràng khi người phê duyệt vắng (đại diện hoặc quản lý trên)
• Một trạng thái cuối cho mỗi yêu cầu (approved, rejected, canceled)

Lỗi 3: Trộn văn bản chính sách và toán học trong cùng một trường

Văn bản chính sách dành cho con người (điều gì được tính, ai đủ điều kiện). Toán cho hệ thống (tỷ lệ, giới hạn, làm tròn, chuyển dư). Lưu riêng để bạn có thể sửa câu chữ mà không chạm toán, và kiểm tra toán mà không chỉnh handbook.

Lỗi 4: Chỉnh sửa và hủy không được ghi lại

Nếu bạn ghi đè yêu cầu, mất “tại sao” dẫn đến thay đổi số dư.

Luôn giữ nhật ký: ai thay đổi gì, khi nào và giá trị trước đó. Trong AppMaster, đây dễ mô hình như bảng lịch sử yêu cầu cộng chuyển trạng thái trong Business Process.

Lỗi 5: Múi giờ và ngày lễ là suy nghĩ sau cùng

Khoảng nghỉ trải dài theo ngày, nhưng phê duyệt và mục lịch dùng timestamp. Chuẩn hoá theo một “múi giờ chính sách” và lưu cả múi giờ địa phương của nhân viên. Đồng thời quyết ngay liệu ngày lễ công cộng có trừ vào số ngày yêu cầu hay không, và áp nhất quán.

Checklist nhanh trước khi triển khai

Trước khi thông báo, chạy một bộ kiểm tra ngắn với một nhân viên, một quản lý và một người từ HR. Bạn muốn chắc hệ thống có cảm giác rõ ràng, không chỉ chạy được.

Dùng checklist này làm cổng go/no-go cho thiết kế hệ thống yêu cầu nghỉ phép:

• Hiển thị số dư: Nhân viên thấy số dư hôm nay và cách các ngày đã duyệt làm thay đổi nó (để không phát hiện ra số dư âm sau)
• Rõ ràng chính sách: Mọi quy tắc viết bằng ngôn ngữ thường (chuyển dư, ngày cấm, thời gian tối thiểu, nửa ngày) và logic khớp chính xác với lời nói
• Xác thực hữu ích: Khi bị chặn, thông báo nói cần thay gì (ngày, loại nghỉ, giờ, thiếu đính kèm), không chỉ “lỗi” hay “không cho phép.”
• Phê duyệt sẵn sàng cho quản lý: Quản lý có thể phê duyệt từ một màn hình với đủ bối cảnh (số dư còn lại, nghỉ trùng trong đội, ghi chú bàn giao) và có thể yêu cầu chỉnh sửa mà không mất thời gian dài.
• Lịch và kiểm toán: Sự kiện lịch được tạo và đồng bộ khi duyệt, thay đổi và hủy; mọi thay đổi trạng thái được ghi với ai làm và khi nào.

Bài kiểm tra thực tế: tạo một yêu cầu, duyệt, sửa ngày, rồi hủy. Nếu bước nào để lại số dư sai, sự kiện lịch cũ hoặc trạng thái không rõ, sửa trước khi ra mắt.

Nếu bạn xây bằng no-code, tính minh bạch quan trọng như tính năng. Trong AppMaster, bạn có thể giữ mô hình dữ liệu (loại nghỉ, số dư, phê duyệt) và luồng phê duyệt trong các trình chỉnh sửa trực quan, để HR và ops xem hệ thống thực sự làm gì. Bạn cũng có thể mở API cho đồng bộ lịch và tái sinh mã nguồn sạch khi chính sách thay đổi, thay vì chồng các vá lộn xộn theo thời gian.

Khi phiên bản đầu ổn định, mở rộng từng chiều: thêm loại nghỉ, thêm quy tắc định tuyến, rồi thêm tích hợp.

Ví dụ kịch bản: từ yêu cầu đến lời mời lịch

Một nhân viên mới, Maya, bắt đầu ngày 10/3. Hệ thống hỗ trợ tích lũy hàng tháng, nên Maya được cộng PTO vào ngày đầu mỗi tháng. Ngày 12/4, cô ấy yêu cầu nghỉ nửa ngày: 3 giờ Thứ Sáu tới cho khám bệnh.

Mỗi người thấy khác nhau:

• Nhân viên (Maya): số dư hiện tại, số giờ yêu cầu sẽ dùng, và cảnh báo rõ nếu số dư sẽ âm.
• Quản lý: tóm tắt ngắn (ngày, giờ, lưu ý bàn giao) kèm tuỳ chọn phê duyệt, từ chối hoặc ủy quyền.
• HR: chính sách dùng cho tính toán, nhật ký kiểm toán và cách tái tính nếu luật thay đổi.

Maya gửi yêu cầu. Quản lý của cô đang nghỉ, nên hệ thống kiểm tra cài đặt đại diện và chuyển tới quản lý tạm quyền. Người này duyệt.

Khi duyệt, hai việc xảy ra: yêu cầu khóa với phiên bản chính sách đã dùng, và một sự kiện lịch được tạo tên “Maya - PTO (3h)” đúng ngày giờ. Maya ngay lập tức thấy trạng thái “Approved” và lịch báo “Added.”

Tháng Sáu, HR cập nhật chính sách giữa năm (ví dụ, tăng tỷ lệ tích lũy sau 90 ngày). Số dư cần được tính lại, nhưng các yêu cầu đã được duyệt trước đó không được thay đổi lặng lẽ. Hệ thống tính lại số dư hiện tại từ ngày hiệu lực trở đi và lưu lại giá trị trước/sau trong nhật ký.

Một tuần sau, Maya sửa ngày yêu cầu (khám dời). Vì đã duyệt trước, thay đổi thành “Change request” và gửi lại cho người phê duyệt tạm quyền. Sau khi duyệt lại, sự kiện lịch hiện tại được cập nhật (dùng cùng ID sự kiện), không tạo bản sao.

Điều này dễ mô hình trong AppMaster bằng cách giữ luồng đọc được: một đường phê duyệt, một kiểm tra ủy quyền, một bước tạo/cập nhật lịch, và một hành động tái tính riêng cho HR khi chính sách đổi.

Các bước tiếp theo: phát hành phiên bản đầu và lặp an toàn

Cách an toàn nhất hoàn thành thiết kế hệ thống yêu cầu nghỉ phép là phát hành phiên bản nhỏ mà mọi người có thể tin tưởng, rồi mở rộng. Bắt đầu với một policy (ví dụ PTO) và một đường phê duyệt (nhân viên -> quản lý). Khi điều đó ổn, thêm loại nghỉ, vùng địa lý, hoặc các trường hợp cạnh.

Trước khi mở rộng, quyết vị trí nguồn sự thật. Nếu hệ thống HR của bạn là bản chính, app của bạn chủ yếu xác thực, định tuyến phê duyệt và đồng bộ kết quả trở lại. Nếu app của bạn là bản chính, bạn cần nhật ký kiểm toán rõ ràng và kế hoạch khi dữ liệu HR thay đổi (quản lý mới, chuyển phòng, ngày chấm dứt).

Kế hoạch phát hành thực tế ban đầu:

• Thực hiện một loại nghỉ với số dư rõ và một quy tắc tích lũy duy nhất.
• Thêm một bước phê duyệt quản lý và một đường override cho HR.
• Tạo đồng bộ lịch đơn giản chỉ cho thời gian đã duyệt.
• Giữ màn hình admin nơi cài đặt chính sách dễ đọc cho người không chuyên.
• Thêm báo cáo cơ bản: ai đang nghỉ và các vắng mặt sắp tới.

Viết 5–10 kịch bản kiểm tra thực tế và chạy lại sau mỗi thay đổi. Dùng trường hợp từ đội bạn, không chỉ ví dụ giả tưởng. Ví dụ: ai đó yêu cầu Thứ Sáu vào Thứ Năm, ai đó sửa yêu cầu sau khi duyệt, hoặc quản lý duyệt khi nhân viên ở múi giờ khác.

Nếu xây bằng công cụ no-code, tính minh bạch quan trọng ngang tính năng. Trong AppMaster, bạn giữ mô hình dữ liệu và luồng phê duyệt trong trình chỉnh sửa trực quan để HR và ops kiểm tra hành vi thật sự. Bạn cũng có thể mở API cho đồng bộ lịch và sinh lại mã nguồn sạch khi chính sách thay đổi, tránh chồng vá dần dần.

Khi phiên bản đầu ổn định, mở rộng theo từng chiều: thêm loại nghỉ, quy tắc định tuyến, rồi tích hợp.