Payroll

In determining where an employee’s pay should be distributed, the system looks at a hierarchy of fields to determine where to charge an employee’s payroll expenses. First, the process looks for pay costing setup at the Appointment; if none exist it will then look for a Position costing, and finally it will look at the Department costing if there is no costing for appointment or position for that employee.

Appointment costing is always linked to a specific Employee and Job Record. An Appointment costing should be input when an employee is OPS and the Pay Group is POH or POS. Only in rare circumstances does an employee who has a Position number ever have a costing established under Appointment costing.

Position costing is linked to a specific position within a Oracle HR Department. It does not matter what employee is assigned to the position. If you have a new employee assigned to an existing Position, you will not need to establish a new pay costing unless you now want the position to be charged to a new chart field string. The pay
costing process will use the pay costing established for a Position regardless of employee turnover within that position. All POSITIONS MUST HAVE A POSITION COSTING.

Department costing is a default costing. When a Oracle HR Department is first set up, an account code is chosen as their default costing which will be used in the event an employee does not have an Appointment or
Position costing established. This default account is always set to an OPS earnings account.

It is important to ensure the proper costing records are established and maintained as any inaccuracies will affect the labor expense for the department and may cause compliance issues, in particular with Contract, Grant and E&G funding sources.

For additional information, please contact Payroll Accounting.

The Oracle HR pay costing process uses percentages assigned to Account Codes for each employee’s payroll expenditures.

For example, departments can establish a simple pay costing record that will distribute 100% of an employee’s payroll expenditures to a single account code. Departments can also establish more complex pay costing records that will distribute an employee’s pay to a maximum of ten different account codes based on a
percentage assigned to each account. Below is an example of pay being distributed to four different Account Codes:

15.000% 000012345
25.000% 000034567
10.000% 000056789
50.000% 000067890
100.000 % Total

Oracle HR requires all pay costing records to total 100%, regardless of an employee’s appointed FTE. For example, employees hired into a department at a total of .50 FTE will also require a pay costing record that totals 100%. Departments with employees that shift between multiple funding sources will need to closely track the hours and adjust the payroll costing accordingly.

Additionally, if the effective date of the change is not equal to the first day of a pay period, the department will need to submit two pay costing updates.

For example, if a faculty member is paid 100% from account 000012345, and then, effective on the fourth day of a pay period, the pay account is changed to 000067890, the department will need to submit two pay costing updates. In the pay period where the change was effective, the costing would be as follows:

30.000% 000012345 (for 3 of 10 days)
70.000% 000067890 (for 7 of 10 days)
100.000% Total

In the subsequent pay period the costing would be as follows:

100.000% 000067890 (for 10 of 10 days)

Colleges and departments may choose to develop their own alternative method of calculating pay costing percentages. Each department should check with the area responsible for inputting their pay costing data for any specific approvals or requirements unique to their area. Once departments have calculated the new pay
costing percentages for employees that change accounts, those changes should be reported to the area responsible for maintaining their pay costing data within Oracle HR.

For additional information, contact a Payroll Specialist.

Because data input to the Pay Costing is used to charge payroll to the departments’ accounts, all data input must be audited to insure accuracy. After each payroll has been confirmed, you will receive an email that the RSA Check and Account Code Validation is ready for review.

If data has been incorrectly entered, contact Payroll immediately. If you have submitted a request for Other Nonrecurring Payment, the account to be charged will not be reflected in the RSA Check, but is in Paycheck Data under ‘additional data link’. In addition, payment requests such as retroactive, overtime, overload, etc., that are to
be charged to an account other than where the employee is currently distributed will also be located in the Paycheck ‘additional data’ area.

Auditing Departmental Ledgers

It is important to audit Departmental Ledgers on a monthly basis. Run Payroll Registers and compare the totals from your register to your Departmental Ledger to complete the monthly audit.

For additional information, contact a Payroll Specialist.

REMAINING SPENDING AUTHORITY (RSA) CHECK

The Remaining Spending Authority (RSA) functionality inFAST ORhas been developed to allow users to preview ("Check") the result of current pay period salary dollars, including employer contributions, posted against current FAST salary budgets. The RSA Check page displays a department's current salary charges to the FAST chart field combinations associated with Oracle HR Account Codes (minus the GL Account Chart field value). Once a biweekly payroll has been confirmed, users can see how the salary charges will affect their current RSA in FAST. Additionally, this functionality allows users to change pay costing and/or transfer budget in FAST and then recheck salary budget RSA against the biweekly salary charges before they actually post to FAST.

To access the RSA check within FAST, the menu navigation is: ...  The RSA is displayed by budget category (Salaries/Fringe or OPS) and is calculated against the amount of budget available for each Chart field combination. Each of the Chart field combinations is viewed as a separate row in the RSA by Chart fields section of the RSA Check page. The status of each projected RSA calculation is reported as Passed, Failed or with a Warning.
 
PASSED RSA Check passes Budget Checking

FAILED May mean one of three things:

1. 1. 1. Chart field contains a Project ID and exceeds the RSA on the Grant child budget (RSA is negative)
      2. Chart field contains a Project ID that is past the Commitment Control (KK) end date on the Grant child budget
      3. No budget exists for the Chart field combination

WARNING May mean one of two things:

1. 1. 1. The child budget is within 60 days of the KK end date
      2. RSA is negative

Note: Other Non-Recurring (ONR) charges are not setup on the Department Budget Table and are not reflected on the RSA Check page. To verify ONR costings, please contact Payroll 813-974-7955