Skip to end of metadata
Go to start of metadata

KPME 1.5 Leave Management integrated with Time and Attendance

The Leave Management Module will allow for organizations and their employees to accrue, request, report and track the use of benefit time (eg. Vacation, Sick) for exempt and non-exempt faculty and staff. Specifically the system will support the following:

  • Configurable rules used to (1) define employees to a particular plan supporting variable accrual rates and plan restrictions (2) define holiday calendars and (3) define leave codes allowing institutions to identify types of leave for balance tracking and reporting.
  • The ability to submit both leave requests and leave usage for routing and approval by supervisors.
  • Integration with the Time and Attendance system allowing employees with timesheets the ability to see requested and approved leave on their calendar along with organizational holidays. Timesheet employees will be provided the ability to report leave usage through their timesheet.

Leave Management Functionality

The Leave Management module must meet the following functionality:

  • Leave Plans - The leave management module must support the ability to define groups called leave plans used to define accrual rules and restrictions. Employees will be attached to leave plans based on criteria defined by the institution. For example, professional staff may be entitled to accrue vacation time at 4 weeks per year for the first 5 years of service and 5 weeks for service greater than 5 years. Biweekly staff may be entitled to 3 weeks of vacation for the first 3 years of service, 4 weeks from 3 to 5 years and 5 weeks for more than 5 years of service. In this example, two leave plans would be created and the appropriate employees would be associated with each leave plan.
     
  • Accrual Categories - The leave management module must support the ability to define multiple types of accruals and corresponding rates based on configurable breakpoints of years, months or hours of service. These "accrual categories" must allow for limits that will drive business logic such as maximum annual usage, maximum annual carryover, transfer options from one category or person to another, maximum allowable balance and an indicator as to whether or not unused balances are paid out at termination. For example, employees may accrue 20 hours per month of vacation and 8 hours per month of sick time. In this example vacation and sick are accrual categories. Additionally, you may restrict carryover of vacation to be no more than 240 hours per year and not allow more than 240 hours to be used in a year. You may also choose to allow for sick time to be converted to vacation time at a rate of .25 hours of vacation for 1 hour of sick.
     
  • Accruals - The leave management module must support the calculation of accrued benefit time (eg. Vacation, Sick) based on rules defined by accrual categories (see above). Accrued time off must be calculated and made available for reporting or planning again and at a frequency established by the institution. The system must support proration of accrued time off based on the employees service date (eg. hired mid month) as well as the employees designated FTE (eg. .50 FTE) percentage. The accrual calculation must be aware of employee attribute changes that impact accruals and recalculate when these changes occur. Accruals must be projected through the end of the reporting year to allow for employees to plan future time off. Finally, the system must recognize when employees record leave types that impact the accruals (eg Absent without pay) and recalculate accruals accordingly.
     
  • Leave Codes - The leave management module must support the ability to define leave codes that will be used by employees to record their time off. These leave codes must be configurable to allow for entry by start and end time, hours or full days. Each leave code may be associated with an accrual category for the purposes of tracking hours used against hours banked. For example, an accrual category of Vacation may have two leave codes associated with it (1) Vacation (2) FMLA Vacation. This allows for employees to record against more specific leave codes both of which apply towards the Vacation bank. The availability of leave codes for reporting by employees and other system roles (eg. Administrator) must be configurable based on the employee type and user role.
     
  • Scheduled Time Off - The leave management module must support the creation of multiple scheduled time off calendars (eg. Holiday Calendar) that can be assigned to employees based on attributes defined by the institution. For example, an institution may wish to create a different holiday calendar for each campus location. Holidays would appear on the employees leave calendar based on the campus attribute for their job. The scheduled time off calendar must support the ability to define the date of accrual and optionally the ability to define the default date for which the holiday should be taken. The system must also provide the ability to expire unused holidays at a configurable point in time. In addition to standard holidays, the scheduled time off feature should allow for the addition of unplanned time off for the population attached to the scheduled time off calendar. For example, if an institution closes due to weather conditions, a "scheduled time off" entry could be placed on the calendar so that it would automatically appear on the employees leave calendar.
     
  • Rules Overrides - The leave management module must provide for the ability to override system defined rules at an employee level. For example, system rules may say that employees accrue vacation at a rate of 20 hours per month for the first 5 years of service. However a new employee may have negotiated receiving 24 hours of vacation a month in their first year. The system should allow an individual employee to accrue at a higher rater prior to the 5 years service if an agreement was made exempting them from the stated institutions policy. The system should also allow for overrides of carry forward balances, accrual limits, balance transfer amounts and other rules on a per employee basis.
     
  • Leave Calendars - The leave management module must allow for institutions to define calendars for which employees will report their leave. These calendars may or may not correspond to payroll calendars. For example, institutions may choose to define leave reporting calendars to be from the 15th of the month to the 15th of the following month while the payroll calendar may be from the 1st to the end of the month for the same employee.
     
  • Routing Hierarchy - The leave management module must support an approval hierarchy relating either position to position or employee to employee. This must be a system level configuration that is chosen at the time of implementation. The system must support multiple employees being in a single position from a routing and approval perspective.
     
  • Balance Transfers - The leave management module must support the ability for employees to transfer balances from one accrual category to another at definable conversion rates. For example, a rule may be defined allowing accrued sick time to be converted to vacation at a rate of .25 meaning that 4 hours of sick will convert to 1 hour of vacation. These transfers may be manual (employee determines the amount they would like to transfer) or automated (system converts automatically based on established rules) The system must also support the ability for employees to transfer (or donate) accrual balances to another employee within the institution. The system must also support the calculation of payout hours resulting from an employee termination.
     
  • Leave Requests - The leave management module must support the ability for employees to request time off in advance and have that request routed and approved by a supervisor. These requests must be timestamped to allow supervisors to apply institutional policies with regard to granting requests. Approved requests should remain on the employees leave calendar as planned time off until submitted as used. Employees must have the ability to changed approved requests with notification being sent to the supervisor. Supervisors must have the ability to deny requests with notification back to the employee.
     
  • Leave Recording - The leave management module must support the ability for employees to report time off by leave code on a frequency defined by the institution and have the reported time off routed and approved by a supervisor. Time off must be validated against accrual balances. The employee must be provided with a summary of balance information to assist them in properly reporting time off (eg. employee only has 8 hours of vacation remaining so any hours out of office over 8 must be recorded as absent without pay). The system must support a single routing step by default with additional levels as an optional implementation task.
     
  • Time and Attendance Integration - The leave management module must be integrated with the time and attendance system such that approved leave requests automatically appear on the employees time sheet. Leave reporting for time and attendance employees should be reported through the employees time sheet with the same business rules in effect for reporting and accruals.
     
  • Notifications - The leave management module must support the automated notifications to employees based on a distinct list of events. The events / notifications are as follows:
     
    • End of reporting period reminder
    • Employee notification that calendar was modified by someone else
    • Calendar approved / disapproved notification to employee
    • Year end transfer is available
    • Employee delinquent in submitting leave usage
       
  • Reporting - The leave management system will provide limited reporting as it is expected that reporting needs will be specific to institutions. The system will provide however a generic search against leave usage data returning a standard set of columns. Selection criteria will allow for filtering of data based on defined criteria. A example search may be to return all FMLA PTO usage detail for the HR department between Jan 1 and Dec 31 of the current year. The search would return a standard set of columns that could be exported to excel.

KPME Time and Attendance

KPME Time and Attendance provides a system to record hours worked, hours in pay status, and absent time in an easy-to-use, always accessible, web-based interface. KPME Time and Attendance will handle multiple jobs, pay types, and pay cycles based on the employee's active appointments with the institution. KPME Time and Attendance will calculate special rates of pay such as overtime, shift differential, premium, and holiday pay.

The primary objectives of the timekeeping system are:

  • Elimination of paper-based, departmental, or outsourced systems
  • Provide for appropriate approval routing
  • Provide for consistent application of institutional policy as well as state and federal labor laws
  • Provide for easy auditability

KPME Time and Attendance Functionality

The KPME Time and Attendance system provides the following functionality:

  • Access - The system is designed to be accessible 24 hours per day, 7 days a week, 365 days a year.
     
  • Authentication / Authorization - The system supports user authentication methods such as CAS or Shiboleth which may vary by institution. Additionally, the system should allows for role based authorization enabling users access to only those parts of the application that are necessary for their job
     
  • Time Recording - The system supports the recording of time via clock in / out or manual time entry.
     
  • Special Rate Calculation - The system supports the calculation of the following special rates of pay. These calculations are rule based and configurable at various levels such as by campus, department, employee type or individual employee.
     
    • Overtime - The system supports the calculation of both weekly and daily overtime.
       
    • Shift Differential and Premium Pay - The system supports the calculation of shift differential (extra pay received by employees for working a less-than desirable shift i.e., late nights, evenings) and premium pay (a higher rate of pay paid to those working weekends, holidays, vacation days, or working during hours deemed less desirable)
       
    • Holiday Pay The system auto-populates holiday pay based on calendars established through configuration.
       
  • Pay Types - The system supports multiple payment types such as:
     
    • Hourly
    • Flat-rate
    • Dollar based Employees may be paid on an hourly or flat-rate basis and may receive dollar-based pay such as tips.
       
  • Approval Routing - The system supports the routing of timesheets for approval based on the department and work area for which time was recorded. Timesheets may be routed to multiple approvers all of which will be required to approve the portion of the timesheet for which they are responsible. The system will support 1 level of routing by default.
     
  • Audit Capabilities - The system captures all clock actions and time block entries for audit purposes identifying the IP address of the user who made the change.
     
  • Pay Cycles - The system supports multiple pay cycles that are definable by start date / time and end date / time. This allows for institutions to define multiple pay calendars such as monthly, semi-monthly, biweekly, or weekly. For example, an institution may define a pay period beginning at Noon on a Thursday which runs 2 weeks to 11:59:59 am the following Thursday.
     
  • Employment Data - The system provides for integration with employment transaction system for real-time data.
     
  • Earn Codes - Earn code/group configurability.
     
  • Lunch Deductions - Configurable lunch deductions.
     
  • Rounding rules - Grace period rounding, configurable at multiple levels.
     
  • Missed Punch -
     
  • No labels