The Request for Personnel Action (RPA) automates the processing of personnel actions. The RPA resembles the familiar paper SF-52 form and is easy to use. When you process a personnel action, the application automatically generates and configures the RPA based on the Nature of Action Code (NOAC). For example, when you enter the person's name in Part B of the RPA, the application automatically populates the RPA with the applicable person, position, assignment and pay-related information.
The RPA simplifies data entry by:
Grouping Nature of Action Codes (NOACs) into families of related actions
NOACs are grouped into families of related actions and assigned a family type that determines how the application populates data in an RPA. For example, the family type determines which fields the user must complete before updating the action to the database and which business rules run before the update occurs.
See: Nature of Action Families, Configuring, Reporting, and System Administration Guide
Shading data fields to indicate where to enter data
Automatically entering related information based on the person and position such as the pay plan, job occupation code, and grade level based on the actions' effective date
Supplying default values for extra information
Providing selected lists of values based on the NOAC, for example for Legal Authorities and Remarks
Automatically entering required Remarks
Computing pay amounts, based on the pay components such as pay table, grade, step, and PRD
If supporting documentation is required, you can attach documents or use the Notepad for comments.
Many actions require position and person information. You can access the Person, Position, and Position Description windows from the RPA, enter data there, and return to the RPA window.
See: Request for Personnel Action Window
When you process an RPA, business rules ensure accurate pay calculation and validate data entry. The business rules are derived from sources such as the Guide to Processing Personnel Actions, the Guide to Personnel Data Standards, the Code of Federal Regulations, United States Code, Government Organizations and Employees, and other federal personnel pay regulatory guidelines.
Using Oracle Federal HR, you can process the following personnel actions:
Appointment
Award/One-Time Payment
Cancellation/Correction
Change Actions
Change in Data Element
Change in Duty Station
Change in FEGLI
Change in Hours
Change in Retirement Plan
Change in SCD
Change in Tenure
Change in Veterans Preference
Change in Work Schedule
Name Change
Conversion to Appointment
Detail Actions
Extension of NTE
Federal Position
Abolish
Establish
Review
Federal Position Change
Incentive
Living Benefits
Non Pay/Duty Status
Phased Retirement
Realignment
Reassignment
Recruit/Fill
Return to Duty
RIF Exception
Salary Change
Change to Lower Grade, Level or Band
Denial of Within-Grade Increase
Locality Pay
MD/DDS/Nurse Pay
Other Pay
Pay Adjustment
Promotion
Irreg Performance Pay
Step Adjustment
Ref WRI/Ref Perf Pay
Termination of Grade Retention
Termination of Interim WGI
Separation
Student Loan Payment
By routing the RPA, you can ensure that you have captured and reviewed the necessary data and obtained the appropriate signatures before the final approval and update to the database. When processing the RPA, you can save the RPA to your workflow worklist or route the RPA to the next destination within your routing group.
See: RPA Signatures and Approvals, Refreshed Data and Data Maintenance,
As you route the RPA, the application maintains a history of actions. By referring to the history, you can learn what action was taken, by whom, and on what date.
See: RPA Actions Based on Roles
After approving an RPA, you can submit the RPA for update to the HR database. You have the flexibility of immediately updating actions with current or retroactive effective dates. If the RPA has a future effective date, the application applies the necessary checks and edits and prompts you for any missing information. When the effective date is reached, the application reapplies the edits and notifies you of any missing information. After supplying the information, you can resubmit the RPA for update. After the update, you can then process further transactions against these records, including Cancellation and Correction actions.
See: RPA Update to the Database, Retroactive and Future Actions, Correction Actions
Your role and responsibility assigned to your logon determine your access to the RPA and the data that you can view, enter, and change. Your assigned workflow role and routing groups further determine which RPAs you process.
For additional security, an agency you can limit access to sensitive data fields by creating a restricted version of the RPA and associating it to a responsibility.
See: Creating a Restricted RPA
When you update the RPA to the database, you can have the application automatically print the Notification of Personnel Action (Standard Form-50), or you can choose to manually print the RPA or a batch of RPAs from the concurrent manager.
See: Printed Notification of Personnel Action
If your agency uses the National Finance Center (NFC) as an HR or payroll provider, you can generate extracts of the Notifications of Personnel Actions and submit this data to NFC.
See: National Finance Center Interface, Oracle HRMS Configuring, Reporting, and System Administration Guide
To make it more convenient to view frequently accessed information about an employee, you can view information such as assignment and position details, pay and benefits, as well as the actions processed for that person in the Manager and HR Manager Views windows.
See: Information Overview, Oracle HRMS Configuring, Reporting, and System Administration
To use the RPA, you need to understand the following key concepts and activities:
NOACs, Configuring, Reporting, and System Administration Guide
Workflow, Configuring, Reporting, and System Administration Guide
The Federal Request for Personnel Action form (RPA) automates the processing of personnel actions. The RPA resembles the familiar paper form (Standard Form 52) and is easy to use.
The application configures the RPA based on the Nature of Action family selected, the user's role and responsibility, and workflow role. Lists of values simplify data entry, and business rules automate the form by performing calculations and validating data.
The application applies position rules, Central Personnel Data File (CPDF) rules, and business rules to ensure database integrity. The position and CPDF rules are derived from the Guide to Processing Personnel Actions, the Code of Federal Regulations, United States Code, Government Organizations and Employees, and other federal personnel regulatory guidelines such as those supporting alternative federal human resource systems.
The user's role and responsibility as recognized by the logon restrict access to the RPA and data entered in the RPA. By selecting the user's responsibility, the administrator determines which menu the user sees and which records the user can access and modify. By assigning the user specific workflow roles and routing groups, the administrator can determine which RPAs the user processes.
For additional security, an agency can limit a user's access to sensitive data fields by creating a restricted version of the RPA and associating it to a user.
The product supports the OPM-mandated Nature of Action Codes. The Nature of Action Codes (NOACs) are grouped into families of related actions. The families determine how data in the form is populated, which fields are required to update the database, what business rules run before update, and so forth.
The application generates and configures the RPA based on the NOAC family information. The RPA form simplifies data entry by:
Grouping Nature of Action Codes (NOACs) into families of related actions
Shading data fields to indicate where to enter data
Automatically entering related information based on the person and position
Supplying default values for Extra Information
Providing selected lists of values based on the NOAC, for example for Legal Authorities and Remarks
Automatically entering required Remarks
Computing pay amounts, based on the pay table, grade, step, PRD, and so forth
If supporting documentation is required, the user can attach documents or use the Notepad for comments.
Many actions require position and person information. Taskflow buttons allow users easy access to the application's person, position, and position description windows as well as the Extra Information flexfields.
Workflow functionality enables the routing of the RPA for data entry, signature, and review before the final approval and update to the database. Based on the agency's practices, the user can route the RPA to the next destination within the routing group--an individual, groupbox, or routing list.
As the RPA is routed, the system maintains a history of actions. By referring to the history, users can learn what action was taken, by whom, and on what date.
When the RPA is updated to the database, the user can have the system automatically print the Notification of Personnel Action (Standard Form-50) or manually print it from the Concurrent Manager.
After the HR specialist approves the RPA, the HR specialist can submit the RPA for update to the HR database. For RPAs with current or retroactive effective dates, the application validates the data by applying database, position, assignment, agency, and Central Personnel Data File (CPDF) edits. If the edits pass, application immediately updates the corresponding data in the personnel records. The data is then available for further transactions, including cancellation and correction actions.
If any information is missing, error messages inform the user which data fields the user must complete or correct. After correcting the information, the user can resubmit the form for update.
If the RPA has a future effective date, the application applies the necessary checks and edits, and prompts the user if any information is missing. When the effective date is reached, the application reapplies the edits and notifies the user of any missing information. (A process the administrator sets up in the Concurrent Manager initiates the processing of future actions.)
If the Servicing Personnel Office determines that information on a Notification of Personnel Action is inaccurate or an action is invalid or improper, the HR specialist can issue a Correction or Cancellation.
Using the automated Request for Personnel Action standard form (RPA), supervisors and managers can process employee and position actions, and the Personnel Office can record staffing and classification actions.
The RPA online form consists of tabbed sections that correspond to the paper form. For easy reference, the RPA also includes the field numbers that appear on the paper form.
To make data entry easier, shading is used to indicate where you can enter or only view data. The following table describes the actions you can take based on the field color.
| Field Color | Meaning | Process Method |
|---|---|---|
| White | Enter or edit data | User Enterable (UE) or Auto Populate User Enterable (APUE) |
| Gray | View displayed data. If the field contains no data, skip the field. | Auto Populate (AP) or Non Enterable (NE) |
| Asterisks | Skip the field (the application hides the data) | Non display |
Taskflow buttons on the form provide easy access to related windows, such as the People and Position windows and the history of actions taken on the RPA.
You can limit users' access to taskflows when you set up responsibilities.
The actions that you take and the amount of information that you complete on the RPA form depend on the role that you're assigned and your agency's business practices. In general, only Personnelists are assigned all roles.
You can have more than one role for a given routing group and you may belong to more than one routing group. The following table describes the valid combinations of roles.
| Role | Can also be assigned role(s) as |
|---|---|
| Initiator | Requester Authorizer Personnelist Approver (if assigned as Personnelist) |
| Requester | Initiator Authorizer Personnelist Approver (if assigned as Personnelist) |
| Authorizer | Initiator Requester Personnelist Approver (if assigned as Personnelist) |
| Personnelist | Initiator Requester Authorizer Approver |
| Reviewer | Initiator |
| Approver | Initiator Requester Authorizer Personnelist (must be assigned this role to approve actions) |
Managers are often assigned the role of Initiator, Requester, Authorizer, or Reviewer. The roles of the Personnelist and Approver are usually reserved for employees in the Human Resource Office. In general, Personnelists and Approvers are assigned all the roles so that they can fully process an RPA.
The following table describes what actions a user can take when assigned a specific role.
| If your role is.... | You can... |
|---|---|
| Initiator | Create an RPA |
| Requester | Sign in the Requester field, edit data, indicate interim approval |
| Authorizer | Sign in the Authorizer field, review and edit data, indicate interim approval |
| Reviewer | Review the RPA, view data only |
| Personnelist | Indicate interim approval, edit the RPA, complete the RPA, submit the RPA to Update to HR after the RPA has been approved. |
| Approver | Indicate interim approval, edit the RPA, complete the RPA, approve the RPA, submit the RPA to Update to HR |
As a security precaution, if you have more than one role in a routing group, the role you have when opening an RPA from the groupbox determines the role level you have when re-routing the RPA to yourself.
For example, if you are assigned the role of Authorizer and Approver as an individual and assigned the role of Authorizer as part of a groupbox, if you route an action to yourself outside of the groupbox, you may only process the RPA as an Authorizer.
The RPA form includes an Extra Information flexfield for easy entry of:
Personnel data items that accompany the specific NOA that you're processing
Agency data items reserved on the form for agency use (field 25 in the Employee Data section, and fields 40-44 in the Position Data section)
Payroll, performance appraisal, and position description data items required for processing an RPA
When you initiate a Request for Personnel Action, the application displays the Extra Information fields related to the Nature of Action (NOA) family. The fields include data items required to pass the Central Personnel Data File (CPDF) edits, as well as optional data items that accompany a specific NOAC.
The application populates the RPA fields and Extra Information fields based on the effective date, or if there is none, on the current system date. The application supplies values from the database for those data items completed by earlier RPAs or by direct data entry. For example, in a promotion action to a new position, the application displays the values that you entered in the Position Extra Information flexfields when you established the position.
If you taskflow from the RPA to the Person, Position, or Assignment Extra Information, the application datetracks the Extra Information based on the RPA's effective date, or if there is none, the current system date.
Before update, the application refreshes the unchanged Extra Information with data from the database (based on the RPA's effective date). In this way, the application ensures that only new or changed data is updated to the database.
After the application updates the database, you can view the updated data in the forms, Extra Information, and Special Information fields.
See: Refreshed Data and Data Maintenance, Extra Information Types, Configuring, Reporting, and System Administration Guide
The application automatically calculates an employee's pay when you process pay-related personnel actions. For example, calculation rules facilitate processing individual Request for Personnel Action (RPA) actions such as Appointment and Promotion actions, mass salary actions such as Annual Pay Adjustments, and automatic mass actions such as Within Grade Increases.
The pay system or pay schedule associated to the employee's position or retained grade determines the employee's compensation and sets the employee's rate of basic pay. Oracle US Federal HR includes predefined elements for pay and standard and special rate pay tables commonly used in federal agencies.
Increasingly, HR professionals must manage employees under a variety of regulatory systems. The RPA calculates the pay for an employee based on the regulatory system defined in the employee's assigned position. For example, standard and alternative HR systems have different pay cap rules for setting the total salary when the total pay exceeds the total salary cap. The application determines which system governs the person's pay and then applies the appropriate pay calculation rules.
See: Alternative Federal HR Systems
Regulation updates issued by the Office of Personnel Management (OPM) affect how you compensate your employees. For example, the Federal Wage Flexibility Act (FWFA) affects how agencies apply special rate schedules. The RPA process captures the information required to calculate an employee's pay based on these regulations. When you process a salary change action or an automatic Within Grade Increases (WGI) or Quality Step Increases (QSI) for GS and equivalent pay plans, the application determines if the person's position or retained grade contains a special rate table. The pay calculation process sets the Pay Rate Determinant (PRD) based on whether locality or special rate supplement entitlements apply, and then calculates the person's pay accordingly.
Using an RPA mass process, you can update employee and position records when OPM ends a special rate table or a specific pay plan, grade and step combination.
See: Pay Table Changes, Oracle HRMS Compensation and Benefit Management Guide
You can calculate pay based on pay tables commonly used by US Federal agencies. You can also set up agency-specific pay tables and pay plans. For example, you might set up Federal Wage System (FWS) pay tables for regional pay rates.
The predefined pay tables include:
GS and equivalent standard and special rate pay tables for national and worldwide pay plans.
Senior Executive (ESSL) pay tables for SES equivalent pay range pay plans.
Inspector general (IG) pay tables for inspector general pay range plan.
The application also supports FWS pay calculations and supplies FWS equivalent pay plan and grade combinations.
An Assignment extra information segment (Calculation Pay Table) stores the pay table identifier used to calculate the person's current pay.
See: Grade and Pay Structures, Oracle HRMS Compensation and Benefits Management Guide
The application automatically calculates the total pay using the following elements to determine the Total Salary in an RPA:
Basic Pay
Locality Adjustment or Special Rate Supplement where applicable
Adjusted Basic Pay
Other Pay when applicable, including Availability Pay (AP), Administratively Uncontrollable Overtime (AUO), and Supervisory Differential
Total Pay
Automatic pay calculations occur when you process an action that changes the person's:
Position (pay table identifier or valid grade)
Pay Rate Determinant (PRD)
Step or Rate
Duty Station when Locality Area and Percentage Change
Retained Grade
Locality Area and Locality Percentage
If you process an RPA that does not automatically calculate pay, such as an Appointment for an employee with Retained Pay, the application informs you that you must manually enter the pay information, and then opens the pay fields for direct data entry.
If you change information on an RPA that precludes automatic calculation, such as a change from non-Retained Pay to Retained Pay, the application retains the salary information and opens the pay fields for manual entry, and no further automatic changes to salary amounts occur.
The application calculates an employee's annual pay and compares it to a maximum dollar amount to determine whether the employee exceeds the maximum salary amount.
The application performs a pay cap check when it:
Calculates the pay on an RPA or mass action such as a Mass Salary action
Calculates the pay for awards, bonuses, and incentives
For Per Hour employees, the application calculates the Adjusted Basic Pay by multiplying the hourly rate by 2087. The resulting annualized salary is then used to check the maximum allowable amount.
Updates a pay-related action to the HR database
When the application calculates pay, if the Adjusted Basic Pay (Basic Pay and Locality Pay) meets the pay cap limits, the application adjusts the Locality Pay. The application then compares the Total Pay to the aggregate pay limits. Different pay cap rules apply based on the regulatory system that governs the employee.
For example, for standard employees paid under Title 5, if an employee has Other Pay, such as AUO or Availability Pay, the application:
Sets the Total Pay at the capped limit
Displays the amount necessary to reduce the Other Pay as the Capped Other Pay on the RPA. Upon update to HR, the application stores the amount in the Other Pay element.
The application retains the actual authorized amounts for AUO, Availability Pay, and Supervisory Differential. If the pay reaches the aggregate pay limitation, then these nondiscretionary payments carryover to the following calendar year.
For information about pay caps on Adjusted Basic Pay and Total Pay for employees paid under alternative federal human resource systems, refer to Alternative Federal HR Systems
You can appoint Senior Executive Service (SES) applicants to SES pay range positions. When you process an RPA and choose an SES position, the application verifies that the resulting basic pay against the predefined Senior Executive Service (ESSL) pay table for SES equivalent pay plans and ensures that the pay falls within the minimum and maximum allowable amounts for Total Pay and Adjusted Basic Pay. For annual pay adjustments, you can process a Mass Salary action to award percentage increases.
See: Processing a Mass Percent Pay Adjustment, Oracle HRMS Compensation and Benefits Management Guide
If you have employees paid on SES pay tables, you must establish and then certify performance appraisal systems used as a basis for administering salary increases for these employees. When you process pay adjustment actions for SES employees, business rules apply pay cap checks based upon your agency's level of certification: full, provisional, or none.
See: Compensation Actions, Oracle HRMS Compensation and Benefits Management Guide
If you have agency-specific pay range plans, you can define agency pay tables and pay plans and then process individual and mass salary actions for the employees on these pay plans. You define pay range tables and pay plans using the standard implementation steps.
See: Set up Pay Plans, Grades, and Compensation, Compensation and Benefits Management Guide
You can identify and appropriately pay employees serving as Law Enforcement Officers (LEO). You indicate whether a position is a Law Enforcement Officer (LEO) position by entering a 1 or 2 in the LEO Indicator field in Position Group 2 Extra Information. The pay calculation process calculates locality adjustment pay for LEO employees. The application appropriately calculates pay for LEO employees on Oracle Federal Special Rate Pay Table (GS) No. 0491 as a basic rate schedule. For example, the application uses the same rules designated for pay plan GS pay table 0000 to calculate the locality pay for employees on 0491 pay tables with GL and GG pay plans.
You can identify and process pay for inspector general positions. You indicate whether a position is an inspector general position by selecting the IG-00 grade. The application processes the IG type of pay plan using the Oracle Federal Standard Pay Table (AL, ES, EX, GS, GG) as a basic rate schedule. Only Pay Rate Determinant values 0 and S apply to IG Pay Plan.
You can identify and process pay for physicians or dentists. You indicate whether a position is a physician or a dentist position by entering the Clinical Specialty, Phys and Dent Pay Range Table, and Tier fields in the US Federal Valid Grade Info Extra Information. The application processes GP (GS pay plan for physicians and dentists) and GR (GM pay plan for physicians and dentists) types of pay plan using the Oracle Federal Standard Pay Table (GP, GR) as a basic rate schedule.
When you grant an employee Supervisory Differential, you process an Other Pay action and enter the amount or percentage of differential to pay the employee. The application includes this resulting amount in the calculation of Other Pay, and stores the information in the Supervisory Differential element. If the person's basic pay changes, the application retains the amount of the Supervisory Differential.
If you process a NOAC that changes the pay (702, 703, 713, 500-599, 781, 892, 893, or 894) and the total pay exceeds the total pay cap limit, the application informs you that you must process an 810 NOAC Change in Allowance/Differential to change or terminate the percentage or amount of the authorized Supervisory Differential.
As an HR manager, you compensate employees by processing individual RPA actions or mass actions, including pay increases and pay adjustments. The Date Last Equivalent Increase (DLEI) reflects the date on which employees received their latest equivalent pay increases. The NOAC you select when processing an RPA and the regulatory system defined in the employe's assigned position determine whether the application automatically updates the DLEI data segment of the RPA extra information with the RPA effective date or whether you enter a date.
For example, the application automatically updates all appropriate Appointment actions (NOAC 100s) with the RPA effective date. With Transfer actions (NOAC 130), the DLEI does not always correspond to the RPA effective date, so you enter the DLEI date.
When you process pay increase for an employee on a standard regulatory systems, you grant pay increases based on defined waiting periods. The application updates the employee's Within Grade Increase element with the DLEI. When you process actions for employees on alternative federal HR systems, you grant discretionary pay increases based on performance. The application updates the date for the DLEI with the effective date of the RPA or with a date provided by you.
See: Compensation Actions, Oracle HRMS Compensation and Benefits Management Guide
The process methods assigned to a data field on an RPA for a given NOA family initially configure the RPA form.
The product defines process methods for each Nature of Action (NOA) family based on the Office of Personnel Management (OPM) process rules. Process methods determine which fields you can enter or edit.
For security purposes, you can further restrict user access to the data on an RPA by creating restricted forms and assigning them to users. The restricted form is commonly used by the manager or the administrative staff.
Restricted forms don't change the underlying process methods, only the view of the data. You specify which fields you want to set to display only or non-display (the data is replaced by asterisks). When you restrict access to a specific field, such as data of birth, that field is restricted on all personnel actions that the user processes.
The restricted form is particularly convenient for users with roles of Initiator, Requester, and Authorizer who routinely complete selected items.
In addition to restricting the form, you can restrict the user's access to Extra Information.
Changing the process method on a restricted form changes the field display attribute, but doesn't affect how the system processes data.
The following table shows what effect the display and non-display options have on the process methods.
| Processing Method | Restricted Process Method Set to Non Display | Restricted Process Method Set to Display Only |
|---|---|---|
| Non enterable | No change | No change |
| Auto populate | Data replaced by equal number of asterisks | No change |
| User enterable and Auto populate user enterable | Field color is gray Data replaced by equal number of asterisks Can't update or insert data Not navigable |
Field color is gray Can't update or insert data Not navigable |
The application maintains a record of each action taken on an RPA as it is processed. There are two ways to view the history:
From the RPA, choose the History button.
From the Workflow work list, select the RPA, choose Open to display the Workflow notification, and then choose the References button.
The Routing History contains an Action History and a Routing History. You can see the progress of a form as it's routed, including individual destinations and groupbox destinations.
Refer to the status column in the table below for an explanation of each action taken.
| Status | Action taken |
|---|---|
| Initiated | RPA is initiated |
| Requested | Requester signed Part A |
| Authorized | Authorizer signed Part A |
| Reviewed | Reviewer displayed the RPA |
| Update to HR | RPA has been submitted to the database for validation and edits |
| Update HR complete | RPA has successfully passed edits |
| Not routed | RPA was saved but not routed |
| No action | User did not initiate, sign, or cancel the RPA |
| Cancelled | RPA has been cancelled |
| Future action | The approved RPA is held by the system in a separate file until the effective date is reached.You can view the RPA and its history from the Approved Requests for Personnel Action window as explained in Cancelling and Correcting Future Actions. |
Productivity data permits you to assess work loads and to locate problem areas so that you can reduce conditions causing delays. The application includes functionality for entering and maintaining this data.
When you route an RPA, the application enters an RPA status in the Routing History, such as Authorized. Some actions that you take to process an RPA are external to the RPA, such as placing phone calls or obtaining confirmation from another organizations. You can record these actions using the Event History window.
When an event (action) occurs, you enter an event code and the start and end date on which the actions occurred. The application automatically supplies the event descriptions and calculates the elapsed time for you in days, skipping weekends. You can also add comments about the event in the comments field.
For example, if you make someone a job offer, you could choose an event code for that action and enter the date on which you made the job offer. When the applicant accepts, you would record the acceptance date, and the application would complete the necessary descriptions and calculate the elapsed time.
Each RPA that you initiate has an associated Event History window as does each Position that you create.
Note: Cancellations and Corrections are new actions, so the Event History for these actions is not a continuation of the original RPA.
The process for completing an RPA follows the steps you usually take when processing the paper version.
If your role is an initiator, you create an RPA; otherwise you respond to an RPA routed to you. You enter the information required by your role on the RPA and when you have entered that information, you route the RPA to the Human Resource Office for regulatory data and signatures. When the action has been approved by the Personnelist and the record updated, you can print the Notification of Personnel Action, send a copy to the employee, and file it in the employee's Official Personnel Folder.
Use the Request for Personnel Action window.
To complete a Request for Personnel Action (RPA)
If you are an Initiator, select a Nature of Action (NOA) family from the Navigator.
The application enters the name of the NOA family in the Action Requested field and shows you which fields to enter for that NOA family. If there is only one Nature of Action code for the family, such as Change in FEGLI, the application enters the Action Requested and NOA code and description.
Note: If you are not an Initiator, open your Workflow worklist, and open an RPA routed to you or your groupbox, as described in Querying Notifications from Your Worklist, Configuring, Reporting, and System Administration Guide.
Choose a routing group, if necessary.
When you initiate an RPA, the application uses the default routing group to which you belong. If you want to route the RPA using a different routing group, choose the Routing Group icon (located on the upper left corner of the form), and select a different routing group from the Routing Groups list.
Warning: You cannot change the Routing Group after you have saved the RPA to your personal worklist or routed it to the next destination.
Select a person by entering his or her last name or social security number. (The application does not allow you to select your own name.)
As a shortcut, you can choose the person's name from the List of Values. Last names are listed alphabetically and by case so that, for example, the last name 'Young' precedes the last name 'de Rosa.'
The application lists any pending actions it finds for the user. Pending actions include current and future actions that haven't been updated to the database.
Complete the fields appropriate to the personnel action that you are processing.
Many of the fields have Lists of Values that you can choose to quickly complete the required data. If the field requires information, such as Remarks, the application displays an insertion dialog prompting you for information. Enter the requested information.
Note: Until you enter an effective date, the application date determines the information the application populates on the RPA form and the values displayed on the List of Values.
Use the tabs to navigate to the other RPA pages. Complete the information requested in each window.
Note: At any time, you can save the RPA to your Workflow worklist and complete it later.
Click the Extra Information button to save the information you have entered so far and to enter the additional data that accompanies the RPA.
Note: If you navigate to the Position or People window to change the extra information, before you begin entering data, confirm that the effective date corresponds to the action's effective date. If necessary, reset the date. See: Extra Information and the RPA.
If you are assigned the role of Requester or Authorizer, enter your signature in Part A of the RPA by choosing your name from the List of Values.
When you are done, save the RPA, and when presented with the choice of routing the RPA, choose Yes.
The RPA dialog presents you with the options to save the RPA to your workflow worklist. You can indicate your interim approval and continue routing the RPA to a person, groupbox, or routing list.
If you are assigned the role of Approver, you can choose the Approval box on the Routing dialog box.
The printed Notification of Personnel Action (SF50) includes the name, working title, and approval date of the Approver who last approved the action.
Update the RPA to the database.
Approvers can update the RPA to the HR database, or route the RPA to the person responsible for updating RPAs.
To have the application print the Notification of Personnel Action (SF50) when it updates the RPA, choose Print Notification from the Routing dialog box.
The option to Print the Notification of Personnel Action is only available after you submit the action for update to HR. See: Printing the Notification of Personnel Action
The product supports current and future dated actions, and the processing of retroactive actions.
The application uses the effective date, or if there is none, the current system date to populate the information on the RPA form and the values displayed on the List of Values.
To set the effective date
Choose a date for the Proposed Effective Date (Part A) from the List of Values calendar or enter one manually.
Choose a date for the Effective Date (Part B) from the List of Values calendar or enter one manually.
When the application updates the RPA to the database, it uses the Effective Date (Part B) as the record date.
Note: The application allows you to customize the view of the date format on the form; however, the printed Notification of Personnel Action displays the OPM format of month, day, year (MM_DD_YY).
The Person and Position Extra Information windows are datetracked. The effective date on the RPA determines which data the application retrieves for the RPA.
If you taskflow from the RPA to the Person or Position Extra Information to correct or supply missing information, the application automatically datetracks these windows to the corresponding effective date.
If you are entering information directly in the Position and Person Extra Information windows without having first taskflowed from the RPA, then you must datetrack these windows to the appropriate effective date.
Note: To easily synchronize data entry, you can choose a baseline date for initially entering and later correcting information. For example, you might choose the date that the person was hired or the date on which you created the position.
For Nature of Actions that require mandatory Remarks, the system supplies the Remark code and description in the Part F section of the RPA. You can't delete the mandatory Remarks.
You can enter the Remarks in any order on the RPA. When the system prints the Notification of Personnel Action, it prints the required Remarks in the order consistent with the Office of Personnel Management (OPM). It prints the non-required Remarks in the sort order indicated on the Remark Codes and Descriptions window.
If the OPM changes a Remark or authorizes a new one, you can edit the Remarks with the maintenance forms (Remark Codes and Descriptions and NOA Codes and Remarks).
See: Maintaining Remark Codes and Descriptions, Configuring, Reporting, and System Administration Guide.
Use the Request for Personnel Actions window.
To enter Remarks
Choose a Remark from the List of Values.
If there is only one applicable Remark, the system enters it automatically.
If the Remark requires additional information, an insertion dialog box appears when you choose the Remark code. Enter the text and choose OK.
If you need to edit the text that you entered, place your cursor in the Remark code field and press the tab key to move to the description field. The dialog box appears again, and you can change the text there.
Free form insertion of Remarks are supported for all Nature of Action Codes in Part D-Remarks by Requesting Office. You can enter up to 2000 characters and you can enter more than one ZZZ Remark, if necessary.
Note: The Yes/No buttons in Part D are only available when processing a separation action. If you choose Yes, the system sets the Remark section to non-enterable to prevent any data entry. Attach supporting documents for the resignation or retirement using the functionality explained in Enclosing Attachments and Notes.
To enter your own text for a Remark
Choose the ZZZ Remark to display a text entry field where you can enter the applicable text.
You remove automatically inserted Remarks by replacing them with other Remarks.
To remove Remarks
Place your cursor in the Remarks field and choose the Delete icon from the toolbar.
Choose a different Remark from the List of Values.
The product includes predefined Legal Authority Codes (LACs) and descriptions that you can choose when processing an RPA.
If the OPM changes a Legal Authority or authorizes a new code, you can edit the Legal Authority Codes with the maintenance forms.
See: Maintaining Legal Authority Codes, Configuring, Reporting, and System Administration Guide
Use the Request for Personnel Actions window.
To enter Legal Authority Codes
Choose a Legal Authority Code from the List of Values.
If there is only one applicable code, the application enters it automatically.
The LAC codes contain multiple descriptions. Based on your requirement, you can select any one of the descriptions for a Legal Authority Code (LAC).
If the Legal Authority code requires additional information, a dialog box appears when you choose the code. Enter the text and choose OK.
To edit the text that you entered, place your cursor in the Legal Authority code field and press the tab key to move to the description field. The dialog box appears again, and you can change the text there.
You delete a LAC by removing or replacing it.
To remove or replace Legal Authority Codes
Position your cursor in the Legal Authority Code field and choosing the Delete icon from the toolbar.
Choose a different Legal Authority Code from the List of Values.
When processing a RPA, you can attach a note that travels with the RPA. This note is not printed with the Notification of Personnel Action.
If you need to submit supporting documents with an RPA, you can use the attachment functionality. See: Using Attachments, Configuring, Reporting, and System Administration Guide.
Use the Notepad window.
To attach a note:
Choose the Notepad icon located on the top left corner of the RPA.
Choose the New button.
Enter the text.
Choose OK.
Use the Notepad window.
To add or edit text
Open the Notepad.
Choose the Append button and choose OK.
Use the Notepad window.
To delete a note
Open the note.
Choose the Delete button and choose OK.
For actions that share the same effective date, the Office of Personnel Management (OPM) has authorized that agencies can process dual actions on the same RPA. For example, an agency can process a Change in Work Schedule that has the same effective date as a Reassignment.
Some actions you must process as separate actions. For example if you are processing a pay action such as a pay adjustment or a Within Grade Increase on the same effective date as a Return to Duty, Non Pay or Extension of Not To Exceed action, you must process a second action, not a dual action.
If you need to cancel or correct an RPA that contains dual actions, cancel or correct each action separately. See Cancelling or Correcting an RPA.
Use the Request for Personnel Actions window.
To process a dual action
Follow the usual steps for initiating an RPA.
Enter a First Action Nature of Action Code.
Enter a First Action Legal Authority Code.
Enter a Second Action Nature of Action Code.
Enter a Second Action Legal Authority Code.
Continue processing, routing, and approving the RPA as usual.
Note: Certain dual actions require that you enter two Legal Authority Codes (LACs) for both Nature of Action Codes. If you receive an error message when you update a dual action to the HR database, make sure that you have the entered the appropriate LACs for both actions.
If you receive an RPA that requires a different action, you can change the Nature of Action family using the Change Family button. For example, a manager may initiate a Recruit and Fill, which the Personnelist may change to an Appointment.
Because most Change of Family actions involve replacement actions based on the verbal approval of the Requestor and Authorizer, the application retains the information in Part A.
Use the Worklist window.
To change families
Locate the RPA that you want to change in the worklist window and open it.
Choose the Change Family button.
Note: The application supports Change of Family functionality for all Nature of Action codes except Cancellation and Correction actions.
Choose a family of Nature of Actions from the Families list.
The application re-enters the information in Part A and clears the rest of the information.
Enter the Nature of Action code on the RPA.
Continue to enter data, following the usual process for completing and routing the RPA.
Each RPA that you initiate has an associated Event History window as does each Position that you create. You can enter information about actions required in processing an RPA that are external to completing an RPA, such as placing phone calls or obtaining confirmation from another organizations.
You record information about these actions using the Event History window.
To enter productivity data
From the RPA or Positions window, click the Others button and select Event History in the Navigation Options window and click OK.
In the Event History window, choose an Event Code from the list of values.
The application enters information, such as the Description and Category Code, the Start and End Date descriptions. It displays the Standard (STD) Completion Time and automatically calculates the elapsed time, skipping weekends. .
Enter a Start or End Date if you are beginning or ending the activity. (If the application entered a default date and that date does not reflect when you started or ended the activity, you can change the date.)
In the Comments field, enter information about the activity.
Save your information.
The product comes with a standard RPA and a restricted version, Oracle Federal Restricted Request for Personnel Action. The standard unrestricted form includes all the fields that the HR Specialist can access. The restricted form limits the data fields provided and masks commonly restricted data items, such as the social security number and date of birth.
Agencies can create their own restricted forms that limit users' access and view of specific fields and data items.
Use the Application Utilities Lookup window.
To create a restricted RPA
Query GHR_US_RESTRICTED_FORM.
In the Code field, enter the form name that you want to appear on the US Government User Information List of Values.
In the Meaning field, enter the descriptive name that's listed in the List of Values for the Restricted Form Process Methods window.
Choose the Enabled box to enable the form.
Use the Restricted Forms Process Methods window.
To add fields to the RPA
Query the Restricted Form Name field to see the list of available forms names.
Select a form name.
In the Data Field Name, choose the RPA field from the List of Values that you want to change.
In the Restricted Process Method, choose the field display from the List of Values. You have a choice of defining the field as:
Non display (data is replaced with asterisks)
Display only
Repeat steps 4 and 5 for each data field that you want to change.
The effective date determines when the system updates an approved action to the HR database.
If the action is for the current date or an earlier retroactive date, the application updates the database and generates a Notification of Personnel Action.
The application applies the data contained in the Notification to the appropriate position and personnel records, replacing existing values with ones you entered or changed on your RPA.
If the RPA is for a future effective date, the application performs edit checks at the time the action is updated and again at the effective date.
This edit check permits the application to take into account any intervening changes, such as a salary change that would affect the pay amounts.
If during the edit check, the RPA data does not pass the edits, the application routes the RPA to the Workflow Inbox of the person who submitted the RPA for update so that he or she can make the necessary corrections. Once the corrections are made, the RPA can be resubmitted for update. The application reapplies the edit checks, and if they pass, updates the data to the database.
The application holds actions with future effective dates until the date is reached. You instruct the application to process future actions by setting up a Concurrent Manager program.
If multiple actions occur on the same future effective date for an employee, for example a Mass Salary adjustment and a Within Grade Increase, the application processes the NOAC with the highest priority and returns the other NOACs to the person who submitted the action for update to the database for review and possible cancellation or correction. For example, if an employee is due a Mass Salary and a promotion on the same effective date, the application would process the Mass Salary (the NOAC with the highest priority), and return the promotion to the person who updated the database.
If multiple actions occur on the same current or retroactive date for an employee, when you update the action, the application displays a message that lists actions that have been updated on that day as well as pending actions. You can then take the necessary steps to cancel or correct the other actions.
Warning: Do not change the NOAC order of processing. The order of processing is predefined so that employee records are properly updated and maintained. Changing the NOAC order of processing may severely impact the database when you update records. For example, if you assign Pay Adjustment NOAC 894 a lower processing number than Promotion NOAC 702, the application may incorrectly calculate the employee's promotion salary.
When you open an RPA from your Worklist or route it, the application automatically refreshes the data. It lists the data that changed due to updated RPAs or manual data maintenance of person and position information.
You can also manually display new or changed data by choosing the Refresh button. You might do this after you:
Navigate to another window, such as the Person or Position window to perform data maintenance on optional RPA data
Enter RPA Extra Information that is also displayed in an RPA fields
For example, if you are processing a Realignment action (NOAC 790) and enter a new position's organization in the Extra Information, you can choose the Refresh button to display it on the RPA.
When you update an RPA to the database, the application lists all RPAs updated on that date for the person or position and any pending future actions. If in reviewing this list, you decide that certain actions affect pending actions, you can cancel, correct, or resubmit these pending actions as warranted.
For example, you might wish to cancel a pending a Within Grade Increase (WGI) if you are updating a Promotion action or to correct the WGI effective date to coincide with the promotion effective date.
See: Canceling or Correcting an RPA
Electronic authentication is based on system security. By basing security on roles, responsibilities, and unique logon names, the application ensures that the user's access and signature is unique to the user and under his or her control.
The role assigned to you as a user determines your signing authority on the RPA form.
The printed RPA in Part C displays the last six Approvers and Personnelists who processed the action by saving the RPA to their Personal Inbox. The signature block includes the:
Personnelist or approver's full name
Personnelist or approver's office (from the Office Symbol field in the Extra Person Information flexfield)
Date that he or she routed the action
Block C-2 of the printed RPA contains:
Last approver's name (first name, middle initial, last name)
Working title (from the Position Working Title field in the Extra Person Information flexfield)
Date the approver approved the RPA
You can designate a different person to sign the RPA than the Notification of Personnel Action (NPA) by determining who approves the RPA and who updates the HR database.
The RPA displays the full name, working title, and the date of the person who last approved the action. The printed individual NPA displays the full name, working title, and the date of the person who updated the action to the HR database.
The Notifications for mass actions such as Realignments, Salary Adjustments, Transfers, and Automatic Within-Grade Increases display the name of the Approving Officer that you entered on the Personnel Office Identifier (POI) maintenance form.
Only employees assigned the role of Approver can approve an RPA. Although the Approver must be assigned the role of Personnelist, in practice, the Approver is usually assigned all roles. In this way, the Approver can perform all the tasks required to process an action and update the employee's records.
The application maintains the date of approval, the data transmitted, and the name and position of the person who took the action. This information is stored as historical data and can be viewed from the Workflow worklist (References button) or from within the RPA (History button).
The application generates a Notification of Personnel Actions (NPA) only on appropriated positions. You can have the application print a NPA when it updates a personnel action to the HR database. You can print:
An NPA when you submit the RPA for update on a current or retroactive action
Note: You cannot use this option to print future actions. When the effective date is reached and the application updates the database, you can print the NPA from the Concurrent Manager or the Workflow worklist.
A single NPA from the Concurrent Manager after the application updates the database
NPAs in batch after the application updates the database
Note: It's recommended that you do not set up a default printer for printing NPAs from the Concurrent Manager. You won't be able to override this choice when you request automatic printing.
The information you approved on the RPA is printed in the NPA. The application also:
Prints the approving official's full name, title, and approval date
Orders and prints the Remarks in the correct sequence
Replaces the numeric steps for Administrative Law Judges (AL) pay plan with alphabetical designation (A-L), and numeric steps for Executive Pay (EX) plan with roman numerals.
Prints the Name and Location of Position's Organization
The application inserts this information from the organization specified in the Position Group 1 flexfield. The organization address or hierarchy information is entered in the Organization window as the HR Organization's Extra Information US Fed Reporting Info.
See: HR Organizations: Entering US Federal Reporting Information, Enterprise and Workforce Management Guide
Electronic authentication is based on system security. By basing security on roles, responsibilities, and each user's unique logon, the application ensures that the user's access and signature is unique to the user and under his or her control.
The role assigned to you as a user determines your signing authority on the RPA form.
To sign an RPA
Sign Part A of the RPA by choosing your name from a List of Values in the appropriate signature block.
If your role permits you to sign as Requester and Authorizer, you can choose your name in both locations.
See: Approving an RPA
Only employees assigned the role of Approver can approve an RPA. If you are not an Approver, you can check the Interim Approval box.
To approve an RPA:
Save the RPA.
In the Routing window, check the Approval box.
The Approver can submit the RPA for edits and update to HR or return the RPA to the Personnelist to update HR.
Note: If you initiate and approve an action without routing it to anyone else, save the RPA to your Workflow worklist before you choose Update HR. By saving it to your worklist, you create a history of that action that is viewable later from your Workflow worklist.
To indicate interim approval
Save the RPA.
In the Routing window, check the Interim Approval box.
Checking this box does not update the personnel records. If you do not approve the action, you can use the Notepad to explain the disapproval, and return it to the Initiator or reroute it.
The RPA also contains a Refresh button so that you can:
Refresh the information shown on the RPA that's entered from the RPA Extra Information
For example, if you are processing a Realignment action (NOAC 790) and enter a new position's organization in the RPA Extra Information, you can choose the Refresh button to display it on the RPA.
Display data maintenance changes without having to close and then reopen the RPA to display these changes.
For example, if you notice that the year an employee attained a degree is entered incorrectly, you can taskflow to Special Information, enter the correct date, return to the RPA, and then choose Refresh to display the data change on the RPA.
To refresh the information on the RPA
Choose the Refresh button.
As a security measure, the system does not allow you to process your own RPA. If someone sends an RPA about you to a groupbox that you belong to, you cannot view the RPA. Similarly, the system prevents you from routing an RPA to a person whose RPA you are processing.
If your agency permits you to process your own RPA, you can do so by creating a dummy employee and routing the action to that person.
You can print using a postscript printer RPAs for those applicants and employees within your security profile. You can print the RPA after the RPA successfully passes the required edits and the application updates the database.
To print an RPA from the Concurrent Manager
Display the Submit Requests window.
In the Name field, select Request for Personnel Action.
Enter the Employee Name in the Parameters window.
The Employee Name list of values displays applicant and employee names. You can print future-dated RPAs for applicants if the person is an applicant as of the system date, and you are using a responsibility that has a security profile set to View Applicants: ALL.
Choose the Submit button.
To print a current RPA
Locate an RPA on the Worklist and open the Notifcation.
Open the RPA by double-clicking the Request for Personnel Action icon.
Print the RPA by choosing the Print icon from the toolbar.
Select Request for Personnel Action.
Select a printer, and choose the OK button.
To print an updated or cancelled RPA
Locate the RPA on the Worklist.
If necessary, use the Find Notifications dialog to display all updated and cancelled actions.
Open the RPA by double-clicking the Request for Personnel Action icon.
Print the RPA by choosing the Print icon from the toolbar.
Select Request for Personnel Action.
Select a printer and choose the OK button.
You print the Notification of Personnel Action for employees within your security profile using a postscript printer after the RPA successfully passes the required edits and the application updates the database.
To print the NPA automatically
Select Update to HR from the Routing dialog box.
Select Print Notification.
Select a printer.
Choose OK.
To delay printing the NPA
Select Update to HR from the Routing dialog box.
Deselect Print Notification.
Choose OK.
When you are ready to print the NPA, print it from the Concurrent Manager or from an updated RPA.
To print a single NPA from the Concurrent Manager
Display the Submit Requests window.
In the Name field, select Notification of Personnel Action.
Enter the Employee Name in the Parameters window.
If you wish to have the application print the back page of the NPA, choose Yes.
Choose the Submit button.
To print a batch of NPAs from the Concurrent Manager
Display the Submit Requests window.
In the Name field, select Batch Print Notification of Personnel Action.
Enter print criteria in one or more of the following fields:
Employee Name
NOA Code: application prints NPAs that correspond to the specified Nature of Action Code
POI: application prints NPAs with the specified Personnel Office Identifier
Organization Group: application prints NPAs for the employees in those organizations whose names include the text you enter in this field
The Organization Group and Organization fields are mutually exclusive. You enter information in one or the other.
Use Organization Group to print NPAs for more than one organization in a business group. For example, if you defined organization names with regional designations such as Northeast Office and Southeast Office, you could print NPAs for employees located in these organization by entering east in the Organization Group.
Additional Information: The application locates the NPAs for any organization whose name contains the text entered in Organization Group. To retrieve NPAs for the relevant organizations, make sure that you enter text found only in the names of the organizations that you wish to query.
Organization: application prints NPAs where the position's organization is the same the one entered in this field
The Organization Group and Organization fields are mutually exclusive. You enter information in one or the other.
Reprint Printed RPAs: application prints notifications that have been previously printed. Select No to avoid printing them.
Back Page: application prints the back page if you enter Yes
From Effective Date: application prints those NPAs with an effective date that falls on or before the specified end date
To Effective Date: application prints those NPAs with an effective date that falls on or before the specified end date
From Approval Date: application prints those NPAs with an approval date that occurs on or before the specified end date
To Approval Date: application prints those NPAs with an approval date that occurs on or before the specified end date
Choose the Submit button.
The application prints the NPAs in alphabetical order by employee Last Name.
Note: Last names in the application are listed alphabetically and by case. For example, the last name"'Young" precedes the last name "Arlen."
When you initiate an RPA for someone, the application displays a list of pending actions (actions that have not yet been approved for that person). By reviewing the RPAs, you can determine whether pending actions affect the one that you are processing.
When you initiate a correction or cancellation that has a future or retroactive effective date, the application displays a list of approved RPAs. By reviewing the RPAs, you can determine whether these actions need to be cancelled or corrected.
The Approved Request for Personnel Actions window lists the approved actions for each person you query, including:
All future RPAs that have been approved
Notification of Personnel Actions that have an effective date later than the one you are correcting or canceling
Notification of Personnel Actions where the Nature of Action is the second Nature of Action of a dual action
Retroactive actions allow you to make necessary adjustments to an employees record. They are processed the same as other actions, with the exception that the effective date of a retroactive action is earlier than the current date. When the action is approved and submitted as an update to HR, the application performs the usual CPDF edits.
If you rehire an ex-employee and need to change that person's record, it is recommended that you process an RPA based on the current Appointment, and not a retroactive action for the previous Appointment. For information about retroactive actions and corrections to intervening actions, refer to Processing Retroactive Actions, and Canceling or Correcting an RPA.
HR Managers and Administrators often prepare RPA transactions in advance, for example, in expectation of a mass pay adjustment based on newly released pay table updates. A future action is an RPA that has an effective date later than the current date. In practice, it is usually an action with an effective date later than current pay period.
You process future actions the same as any other Nature of Action, with the exception that you set the effective date later than the current date. You initiate a future action, route it, approve it, and update it to HR. When the application runs the Process Future Dated RPA concurrent process (based on the frequency established by your system administrator), the application identifies the actions due for update, performs the necessary CPDF edits and updates the actions to the HR database.
See: Scheduling Future Dated RPA Actions
At the time of update, the application routes any pending RPAs for the employee to the person who submitted the actions for update. This person can then review the RPAs and take appropriate action, Correcting, Canceling, or resubmitting the RPAs for update.
If multiple actions occur on the same future effective date for an employee, the application processes the NOAC with the highest priority and returns the other NOACs to the person who submitted the action for update for review and possible Cancellation or Correction.
After the application updates the database with that day's actions, you can print the Notification of Personnel Action from the Concurrent Manager.
See: Printing the Notification
If the Servicing Personnel Office determines that information on a Notification of Personnel Action is inaccurate or an action is invalid or improper, the Personnelist can issue a Correction. The Approved Requests folder lists the original RPA, Correction, and Cancellation actions performed against it, and the NOAC order in which the RPAs were processed.
When you process a Correction, you can update any editable field, including an employee's first, middle, and last names as well as their Social Security Number and Date of Birth. Iis recommended that you use the Correction personnel action to change data items for an employee's Person, Assignment, or Position record rather than enter manual changes in the Person, Assignment or Position windows. When you update the RPA action to the HR database, the application updates the employee's record and maintains a history of those changes.
When you process a Correction to an action, the application uses the To Side position information of the most recent NPA. The application uses the From Side only when the NPA is a Cancellation of an Award, Separation, or Non Pay Duty Status action.
If several intervening RPAs have the same effective date, you can refer to the NOAC Process Order number in the Approved Requests for Personnel Action window to determine the sequence in which to Cancel or Correct the RPAs.
Note: If you have several intervening actions with the same effective date, the element displays the most recent updated value. The application only changes the element when the final intervening action is updated, not for the ones with lower process order numbers.
Position data that you change manually in the Position window is not considered a retroactive change. To include those data item changes in an action, Cancel the original RPA and process a new action.
You can process actions with future effective dates to prepare RPAs in advance. A future action is an RPA that has an effective date later than the current date. In practice, it is usually an action with an effective date later than current pay period.
Use the Submit Requests window.
To process a future action
Initiate an action and enter an effective date later than the current date.
Until you enter an effective date, the application populates the RPA with information based on the current date. Prior to entering the effective date, you can view information for a later or earlier date by date tracking the RPA.
Process the action as you would any other RPA completing, approving, and updating the action.
See: Processing a Request for Personnel Action
When the application runs the Process Future Dated RPA concurrent process for the action's effective date, the application reapplies CPDF edits to validate the information contained in the RPA. After the application updates the database with that day's actions, you can print the Notification of Personnel Action from the Concurrent Manager
See: Setting the Frequency for Processing Future Dated Actions
If you prepare RPAs in advance of the effective date, you can have the application update the actions to the database when the effective date is reached. To have the application process future-dated RPAs, you specify how often the application retrieves and updates to the database those RPAs that have reached the effective date. For example, you might schedule the process to run nightly, and the application would update those RPAs effective that day.
The number of transactions due for update on a given day may run into the thousands, such as a mass salary update. To improve the performance and expedite the number of transactions run, you can specify the number of batches to run simultaneously (number of threads), and the number of transactions in each batch (batch size).
You do not have to belong to the groupbox of the user who initiated the RPA; the responsibility you choose when logging onto the application determines which future-dated RPAs you can schedule. When you log in with a:
Secure view responsibility, you can schedule the process for future-dated RPAs created in that secure view responsibility
The application retrieves those RPA records where the business group ID of your current login matches the business group ID of the RPA originator's login.
Non-secure responsibility, you can schedule the process for all future-dated RPAs
If you have set up cross-business group functionality, the process runs for RPAs in all business groups. Otherwise, it runs for RPAs in your current login's business group.
Use the Submit Requests window.
To schedule the process for updating future dated actions
In the Name field, select Process Future Dated RPAs from the list of values.
In the Parameters field, enter the:
Personnel Office ID
By specifying the POI, you limit the RPAs processed to those administered by that personnel office.
Batch Size, the number of transactions in each batch
The default batch size is 1000.
No. of Threads, the number of batches to run simultaneously
The default number of threads is 10.
To define a schedule, set the Run the Job options to run a request as soon as possible, at a specific time, or repeatedly at specific intervals.
Specify the Completion Options.
Choose the Submit button.
If multiple actions occur on the same future effective date for an employee, the application processes the NOAC with the highest priority and returns the other NOACs to the person who submitted the action for update. The recipient can then review, and if necessary process a Cancellation or Correction action.
When the application processes the actions that are effective for that day, the application reapplies CPDF edits to validate the information contained in the RPA. To account for any system down-time, the application also updates any actions with earlier effective dates that might have been skipped when the system was off-line.
If you have multiple POIs, you can repeat these steps to set up a processing schedule for each appropriate POI.
Retroactive actions allow you to make adjustments to an employee's record that occur earlier than the current date.
Note: For rehired ex-employees, do not process retroactive actions to change the person's record. Instead process an RPA based on the current Appointment. See Rehiring an Ex-Employee
To process a retroactive action
Initiate an action and enter an effective date earlier than the current date.
The application populates the RPA with information based on the current date until you enter the effective date. Prior to entering the effective date, you can view information for an earlier date by datetracking the RPA.
Process the action as you would any other RPA completing, approving, and updating the action.
When the action is approved and submitted as an update to HR, the application performs the usual CPDF edits.
For retroactive action in which you select and then update information about an employee, the application informs you if the employee has intervening action. You may need to review and subsequently Cancel or Correct these actions depending on the purpose or details included in the retroactive personnel action.
For information on processing retroactive and intervening correction actions, see Correcting an NPA.
If the Servicing Personnel Office determines that information on a Notification of Personnel Action is inaccurate or an action is invalid or improper, the Personnelist can issue a Cancellation. The Approved Requests folder lists the original RPA, Correction, and Cancellation actions performed against it, and the NOAC order in which the RPAs were processed.
If you Cancel a non-Appointment action, the application Cancels the action and any Corrections made to it. If you Cancel an Appointment action, the application automatically Cancels all subsequent Approved personnel actions and Corrections and generates an NPA for the starting original action. The application does not generate NPAs for the subsequent actions, but marks them as Canceled so that they are no longer listed in the Approved Requests for Personnel Action window. As a reminder, if you do Cancel an Appointment action, delete any pending RPA's for that person. (Open a pending RPA from your Workflow worklist and remove the employee's name, then delete the RPA.)
To cancel an NPA
Select Cancellation/Correction from the Navigator.
In the Find window, enter query criteria for the Name or Social Security.
You see a list of Approved and future actions. A processed status indicates the action has been Approved and updated to the HR database; a pending status indicates a future action.
In the Personnel Actions region, click Completed, Pending, or All to specify the type of actions that you wish to view for that employee.
From the Approved Requests for Personnel Action window, select the Notification of Personnel Action you want to Cancel. You can only process RPAs for which you are part of the original routing group.
Note: If you are canceling dual actions, you must process a separate RPA for each action. The second action is listed below the first with the number 2 next to it.
Choose the Cancellation button.
The RPA opens with the Cancellation Nature of Action entered. Because the Nature of Action is to withdraw the action, you cannot change the Nature of Action family or the data in the form.
Route, approve, and submit the RPA for update as you would other RPAs.
Note: When you close the Cancellation action, the application places it in your Workflow Worklist where you can continue to work on it. If you delete the Cancellation action before approving and updating it to the database, the application restores the original approved action to the Approved Requests for Personnel Action window.
The application lists future approved actions in the Approved Requests for Personnel Action window. This window lists the approved actions for each person queried, including:
All-future approved RPAs
NPAs that have an effective date later than the one that you are canceling or correcting
NPAs where the NOAC is the second NOAC of a dual action.
See: Processing Future Actions
Use the Approved Requests for Personnel Action window.
To cancel an approved future action
Select Cancellation/Correction from the Navigator.
The Approved Requests for Personnel Action window appears.
Query the future action you want to cancel by entering the query criteria in the Name or Social Security field.
You see a list of approved and future actions. A pending status indicates a future action.
From the Approved Requests for Personnel Action window, select the future RPA that you want to cancel.
Choose the Reroute button to reroute the RPA to the person who submitted the RPA for Update to HR.
Cancellation and Correction actions remain in the action's original routing group.
To cancel the RPA, the person who submitted the RPA for update can route the RPA to the Approver for cancellation. (The Approver opens the RPA and deletes it by choosing the Delete Record icon from the toolbar.)
The action is listed as cancelled in the History for that action.
Use the Approved Requests for Personnel Action window.
To correct an approved future action
Select Cancellation/Correction from the Navigator.
The Approved Requests for Personnel Action window appears.
Query the future RPA you want to correct by entering the query criteria in the Name or Social Security field.
You see a list of approved and future actions. A pending status indicates a future action.
From the Approved Requests for Personnel Action window, select the future RPA that you want to correct.
Choose the Reroute button to reroute the RPA to the person who submitted the RPA for update.
The person who submitted the RPA for update can correct the action, route it to the Approver for approval, and submit the Correction for Update to HR.
When you process a Correction, you can update any editable field, including an employee's first, middle, and last names as well as their Social Security Number and Date of Birth.
Additional Information: You should process any Name Change Corrections (not Cancellation) against the original RPA where the name was entered in error, usually an Appointment or a Name Change action
To correct a Notification of Personnel Action
Select Cancellation/Correction from the Navigator.
In the Find window enter query criteria for the Name or Social Security.
In the Personnel Actions region, click Completed, Pending, or All to specify the type of actions that you wish to view for that employee.
From the Approved Requests for Personnel Action window, select the Notification of Personnel Action that you want to correct.
If the Corrections are hidden from view, choose the Show Corrections button to list them.
If you are Correcting dual actions, you must process a separate RPA for each action. The second action is listed below the first with the number 2 next to it.
Choose the Correction button.
An RPA window opens with the Correction Nature of Action displayed. Enter the data that you wish to correct in the appropriate field.
When you create a Correction action, the application populates the From Position side details with the Position information from the original RPA.
If you are correcting an intervening action, the application retrieves the From Position side data from the most recent retroactive RPA. If the most recent retroactive RPA is a Cancellation action, the application uses the RPA that preceded the Cancellation.
When you process the Correction, you can also review and change the extra information details. The application displays the RPA extra information values entered in the original RPA's extra information, and then refreshes the RPA's extra information with the Position, Assignment, and Position extra information based on the RPA's effective date. You can change the extra information, including replacing previously updated data with a null (blank) value.
Complete and route the RPA, following the usual steps for processing an RPA within the Personnel Office.
If you close the Correction action, the system places it in your Workflow Worklist where you can continue to work on it.
If you delete the Correction action before approving and updating it to the database, the application restores the original action to the Approved Requests for Personnel Action window.
Upon update, the application enters the corrections in the appropriate records for the effective date of the original action. The application creates a Remark noting that the item is corrected, and generates a Notification of Personnel action that you can then print. The printed Notification contains all the information contained in the NPA as well as the corrected data items.
Insertion Data
If you are Correcting an action that has insertion data in the NOAC description, such as an NTE date, you cannot correct this information. If necessary, cancel the action and reprocess it.
To have the application calculate pay using Retained Grade information, you must complete the US Federal Retained Grade Person Extra Information before updating an action to the HR database.
You can enter more than one Retained Grade record for an employee. When calculating pay, the application uses the active record. The application identifies the active records where the To Date has not been reached and chooses the one with the earliest From Date. For example, in the table below, if you are processing an action with an effective date of September 1, 2003, the application would use the first retained grade record since its start date of January 1, 2003 is earlier than the second record's start date of June 1, 2003.
| From Date | To Date |
|---|---|
| 1 - Jan-03 | 31 - Dec-04 |
| 1 - Jun-03 | 31 - May-05 |
If you later change a person's Retained Grade extra information (Retained Pay Plan, Grade, and Pay Basis), the application recalculates the employee's pay upon update to the HR database.
Tip: When you then process an RPA for someone who has a Retained Grade record, it is recommended that you enter the Effective Date before selecting the person's name. Entering the effective date first ensures that the application retrieves the appropriate retained grade details.
Every position has a pay plan and pay table ID. Pay calculations performed for an employee on Retained Grade access the Retained Grade pay table ID, not the position's pay table ID. Similarly, the application calculates pay using the retained pay plan and grade, not the position's pay plan and grade.
When you construct pay tables, confirm whether anyone is on Retained Grade. If so, create Retained Grade pay tables and maintain them until you no longer expect to place anyone on them. When the new pay tables are released, make sure that you update the Retained Grade pay tables.
If an employee is on Retained Grade with a Pay Rate Determinant (PRD) of A, B, E, F, U, or V, the pay fields on the RPA reflect the Retained Grade Pay Basis.
For some employees, the pay basis of the Retained Grade is not the same as their occupied position. For example, an employee might have a mixed pay basis with a per annum pay basis for their retained grade and a per hour pay basis for their position. To make the salary formats commensurable, the application displays the To and From pay amounts in the Retained Grade pay basis.
If you are implementing Oracle US Federal HRMS and you have legacy employees or you are updating your current installation with the Update 34 changes, the following condition applies. For the first action you process for an employee who occupies a retained grade, the From salary information on the RPA displays the occupied position's pay basis and the To salary information displays the retained grade pay basis.
If the occupied and the retained grade pay basis are not the same, the application inserts Remark AAA. This Remark explains that although the salary amount formats are different, the employee's salary remains the same.
All subsequent actions processed with effective dates later than the updated first action display the To and From Salary amounts in the retained grade pay basis.
You can temporarily promote an employee who occupies a retained grade record by processing a NOAC 703 Promotion NTE. When you process a NOAC 703, you enter the Temporary Promotion Step and the Date WGI Due in the RPA Extra Information. Upon update to HR database, the application:
End dates the active retained grade record
Creates a new retained grade record with the same values as the previous record as well as the Temporary Promotion Step
Updates the WGI Due date information in the WGI element
Records the step information in the Person Federal Retained Grade extra information
Displays the Temporary Promotion Step in the RPA and NPA reports
Employees who are temporarily promoted while on retained grade are eligible for Within Grade Increases, QSIs, and pay adjustments. The salary computation is based on the details of the temporary promotion, not the retained grade.
When you first put someone on Retained Grade by processing a NOAC 740 Position Change, you enter the Retained Grade record. The application stores this information in the US Federal Retained Grade Person Extra Information. When you process an Automatic Within Grade Increase for the employee on Retained Grade, the system automatically increases the Retained Step.
When you create a retained grade record, the application end dates the record two years after the record's start date. For example, if the Date From is 10-January-2003, the Date To is set to 10-January-2005. If your agency practices require a two year minus one day interval, you can manually enter a different Date To, such as 09-January-2005.
To keep your changes synchronized, when you:
Create or update a retained grade, date track to the retained grade record's start date.
Terminate a retained grade, enter the effective date before you select the employee so that you can view the records that are active as of the effective date.
You can terminate a retained grade or a Temporary Promotion while on retained grade by processing a single RPA using one of the following NOACs:
702 Promotion
740 Position Change
866 Termination of Retained Grade
The application displays the retained grade information in the RPA Extra Information (US Fed Termination of Retained Grade). If you are processing a:
NOAC 702 action, the application lists all the retained grades to be terminated
A promotion removes an employee from retained grade, so upon update to the HR database, the application automatically terminates all retained grade records. The application end dates the retained grade records one day prior to the RPA effective date. If the employee was on a Temporary Promotion, the 702 action terminates the retained grade as well as the Temporary Promotion and promotes the employee to the current position.
NOAC 740, the application lists all the retained grades and you can terminate one or more of them
You select each retained grade record and enter a yes (Y) to terminate or a no (N) to continue the retained grade. Upon update, the application terminates the records you specified as yes (Y). It end dates the retained grade record one day prior to the RPA effective date.
NOAC 866, the application lists the active retained grade
Upon update, the application terminates the retained grade, end dates the record as of the RPA effective date, and updates the new salary amounts on the day after the RPA effective date.
If the employee has more than one retained grade record, the application places the employee on the next active record (the one with earliest From Date that has not yet reached its To Date.) If the employee is also on Temporary Promotion, when you process the 866 action, you can keep the same step or change it in the RPA extra information. Upon update to HR, the application includes this Temporary Promotion step information in the active record.
You can terminate all active records by processing a NOAC 866 for each one as long as the PRD is other than 0 or 6.
You cannot correct the Retained Grade records terminated by the original action, such as a NOAC 740 or 866 but you can choose new or active records. If you need to change the originally terminated Retained Grade record, cancel the action that terminated the record and process a new action.
The application maintains position-related Work Schedule, Part-Time hours, and Duty Station information in the Assignment and Position Extra Information. You can change this information when you process an RPA, such as a Return to Duty that involves a Change in Work Schedule.
When you process an RPA and choose a new To Position, the application populates the RPA with the To Position's Work Schedule, Part-Time Hours, and Duty Station information as of the RPA's effective date. If you choose a new work schedule or Duty Station and update the RPA, the application enters the same value in the Assignment and Position record to ensure that the records have identical values.
When you process a NOA 781 Change in Work Schedule (NOAC 781) or Change in Hours (NOAC 782), you enter the date for the Date WGI Due in the RPA EIT US Fed Change Schedule and Hours. Upon update to HR, the new Within Grade Increase element:
Stores the date you entered for the Date WGI Due
Stores the date entered in the previous Within Grade element for the Date Last Equivalent Increase
When you process a Change in Work Schedule or a Change in Hours, the application updates the value of the part-time indicator in the Assignment Non-RPA Extra Information when it updates the action to the HR database.
If the work schedule is B, F, G, I, or J, the application updates the part-time indicator with a null (blank) value. If the work schedule is P, Q, S, or T, the application updates the part-time indicator with the value that you entered in the RPA Extra Information.
You can process RPA actions that involve Not To Exceed (NTE) Dates. The dates you enter in the RPA are for record purposes only. When an NTE date is reached, you must initiate an RPA to terminate a temporary person.
To enter NTE dates
Enter the dates in a Nature of Action description or Remark text.
After an RPA has been approved and has successfully been updated, the application populates the Assignment NTE Extra Information with the new dates.
If the action changes the employee's assignment status so that the NTE date no longer applies, upon update the application automatically nulls (clears) the date from the Assignment NTE Extra Information.
Most name changes involve a change to the person's last name. For this reason, when you process a Name Change RPA, the application does not supply a List of Values for the last name field. You can also change an employee's first and middle names using a Name Change RPA.
Use the Requests for Personnel Action window.
To change an employee's name
Choose Name Change from Change Actions listed on the Navigator menu.
Enter the social security number for the person whose name you want to change.
The application displays the first, middle, and last name of the person.
Note: If you choose the social security number after entering the person's full name, the application replaces the name with the name values stored for that social security number. Re-enter the new first, middle, and last names.
Enter the person's last name. If appropriate, change the person's first and middle names.
Complete the RPA, following the usual steps for processing an action.
When the application updates the database, it updates the person's entire name as entered on the RPA (first, middle, and last name).
Note: The name shown in the Employee field at the top of the RPA does not change until the RPA is updated to the database.
Use the Approved Requests for Personnel Action window.
To correct an employee's name:
Select Cancellation/Correction from the Navigator.
The Approved Requests for Personnel Action window appears.
Enter query criteria for the Name or Social Security.
From the Approved Requests for Personnel Action window, select the Notification of Personnel Action that you want to correct.
Note: If you are correcting dual actions, you must process a separate RPA for each action. The second action is listed below the first with the number 2 next to it.
Choose the Correction button.
An RPA window opens with the correction Nature of Action displayed. The information in Part A is retained, but the remainder of the form is not populated. Enter the data that you wish to correct in the appropriate field.
Complete and route the RPA, following the usual steps for processing an RPA within the Personnel Office.
Upon update, the application enters the corrections in the appropriate records for the effective date of the original action. The application creates a Remark noting that the item is corrected, and generates a Notification of Personnel action that you can then print. See: Printing Notifications.
You can process Conversion to Appointment actions using an RPA.
To enter Conversion Dates in an RPA for Conversion
Initiate a Conversion to Appointment action.
Enter the date on which the conversion occurs in the Conversion Date segment of the RPA Extra Information.
Upon update to the HR database, the application replaces existing Conversion dates in the Person US Fed Conversions Extra Information with the new ones from the RPA.
Note: If you did not enter a Conversion Date, the application clears the Conversion Date field .
When you process a Correction action, you cannot replace existing data with a null (empty) value. However, after updating the Correction to the HR database, you can navigate to the Person US Fed Conversion Extra Information and remove the data there.
If you decide to rehire an ex-employee, you can process Appointment and conversion personnel actions for that person. See: Rehiring an Ex-Employee
The two-character Federal Employee Group Life Insurance (FEGLI) codes replace the existing codes as of April 25, 1999. The two-character FEGLI code is displayed on the employee's RPA, Element Entry window after update to HR, on the printed NPA, and within the CPDF Status report.
If you process a retroactive personnel action with an Effective Date prior to April 25, 1999, and on update to the HR database the application notifies you that the FEGLI code may have changed, you may need to change the employee's element record.
To verify or change the FEGLI code
Display the employee's Element Entry window.
Datetrack the Element Entry window to April 25, 1999. You can only change the FEGLI code if you are datetracked to April 25, 1999.
Verify that the FEGLI code is valid for that date. If necessary, change it.
Save the record.
The US Federal government has authorized changes to human resource and payroll systems to give agencies greater flexibility in managing their daily operations. For example, the government has authorized a system called the National Security Personnel System (NSPS) which employs HR practices commonly found in business, such as pay for performance, pay banding, and market pay. The US Federal product describes these emerging systems as alternative federal HR systems (AFHR).
As an HR professional, you must administer the appropriate guidelines, calculate pay, and generate reports based on the applicable personnel system. For example, when you process a NOA 893 Reg WRI action, the resulting pay calculations and updates to extra information depend on which system governs the employee, a standard (non-AFHR) or AFHR system.
To assist you in managing employees under new regulatory systems, you can:
Process RPAs for standard and AFHR employees using AFHR Nature of Action Codes.
The Office of Personnel Management (OPM) expanded the use of Nature of Actions (NOAs) initially reserved for AFHR employees also to cover standard employees. The application determines whether the employee is a standard or AFHR employee, and applies the appropriate validation and processing.
Identify employee personnel systems.
The employee's assigned position determines which business rules and calculations the application uses. The Personnel System Indicator (PSI) identifies positions as non-AFHR (null or 00) or AFHR (01 NSPS). You can record this information in the PSI segment in the US Alt HR position extra information type. You can create new AFHR positions and move standard employees to these positions.
Process pay increases, award actions, pay adjustments, group adjustments, and pay reductions for AFHR employees
Business rules and pay calculations for pay-related NOAs include support for pay for performance and local market supplements.
The Office of Personnel Management (OPM) has issued modifications to existing Nature of Actions (NOAs) and added new NOAs to support alternative human resource systems such as the NSPS. You can process RPAs using the new and changed NOAs. The following table lists the meanings and start dates for these NOAs.
| NOA | Meaning | Start Date |
|---|---|---|
| 713 | Change to Lower Grade, Level or Band | 30-Apr-2006 |
| 840 | Individual Cash Award Rating Based | 07-Jan-2007 |
| 841 | Group Award - Chap 45 | 07-Jan-2007 |
| 849 | Individual Cash Award Non-Rating Based | 07-Jan-2007 |
| 878 | Presidential Rank Award | 30-Apr-2006 |
| 891 | Regular Performance Pay (previously GM Within Grade Increase) | 30-Apr-2006 |
| 892 | Irregular Performance Pay (previously Quality Increase) | 30-Apr-2006 |
| 893 | Reg WRI (previously Within Grade Increase) | 30-Apr-2006 |
| 894 | General Adjustment (previously Pay Adjustment) | 07-Jan-2007 |
The following table lists the NOAs for personnel actions authorized by alternative systems. These NOAs start 07-Jan-2007.
| NOA | Meaning | Process as a Mass Action |
|---|---|---|
| 885 | Lump Sum Performance Payment Rating Based-In Lieu of Pay Adjustment | Yes |
| 886 | Lump Sum Performance Payment Not In Lieu of Pay Adjustment | Yes |
| 887 | Lump Sum Performance Payment Non-Rating Based | Yes |
| 889 | Group Award - Other | Yes |
| 890 | Miscellaneous Pay Adjustment | No |
| 896 | Group Adjustment | No |
| 897 | Pay Reduction | No |
See: NOAC Families and Request Information Types, Oracle US Federal Human Resources Configuring, Reporting, and System Administration Guide
With the increasing number of personnel systems authorized by OPM, HR professionals must find ways to effectively manage employees based on the appropriate regulatory guidelines. You can easily identify an employee's personnel system by entering its associated code in the position extra information (US Federal Alt HR System). The application treats currently or previously occupied positions as standard positions (personnel system indicator of null of 00). You cannot convert these positions to AFHR positions. You must create new positions for employees on AFHR and then move the employees to the AFHR positions.
See: Defining a Position, Oracle US Federal Human Resources Enterprise and Workforce Management Guide
You process pay-related actions for AFHR and standard employees the same way. The principal exception occurs when entering basic pay. After you enter the basic pay, custom code produces the calculations for the local market supplement percentage locality pay, adjusted basic pay, other pay, and total salary values. The application validates the minimum and maximum rates based on the employee's pay rate determinant (PRD).
The application applies the appropriate pay cap checks on adjusted basic pay. When the application calculates pay, the application compares the adjusted basic pay to the pay cap. If the adjusted basic pay exceeds the pay limit, the application sets the adjusted basic pay at the pay limit and subtracts the basic pay from the new adjusted basic pay, entering the resulting amount as the local market supplement (LMS) locality pay on the RPA. If the total pay exceeds the total salary cap, the application sets the adjusted basic pay at the pay limit, subtracts the basic pay from the new adjusted basic pay, and the enters the resulting value as the LMS locality pay on the RPA. The application notifies you that the locality pay has been adjusted to equal the difference between the basic pay and the adjusted basic pay.
The application performs a similar check when validating the total pay. For example, under NSPS, if you authorize Availability Pay and Supervisory Differential, you cannot reduce these payments nor can the employee's total salary exceed the total salary pay cap. If the total pay exceeds the total salary cap, the application subtracts the adjusted basic pay from the total salary cap and displays the resulting capped other pay on the RPA, and enters the unadjusted Availability Pay and Supervisory Differential pay in the assignment element entries.
After update to HR, the application updates the date for the last equivalent increase with the effective date of the RPA for appropriate pay actions.
See: Pay Calculation on an RPA
Pay Increases (891, 892, 893)
You can use the NOAs authorized by the Office of Personnel Management (OPM) to grant pay increases to AFHR and standard employees. For example, you can grant pay increases based on performance criteria rather than the standard waiting periods. The following table describes the pay increases for standard and AFHR employees.
| NOA | Standard | AFHR |
|---|---|---|
| 891 Regular Performance Pay | Process performance-based increases | Process performance-based increases |
| 892 Irregular Performance Pay | Process quality step increases | Grant performance pay increase |
| 893 Regular Within Range Increase | Process within range increases | Process within range increases |
See: Automatic Within Grade Increases, Oracle US Federal Human Resources Compensation and Benefits Management Guide
Award Payments (840, 841, 849, 885, 886, 887)
You can process individual cash awards and lump sum performance awards for AFHR and standard employees as individual actions or mass award actions. (OPM authorized the reuse of NOA 885 as a lump sum performance payment.) For these actions, the application no longer limits the award amount or percentage.
You process award actions the same way for AFHR and standard employees, entering an award amount or percentage in the RPA Award window. The application calculates the result based on the adjusted basic pay. If the pay basis is not per annum, the application determines the award salary by converting the adjusted basic pay to an annual amount. Custom hooks enable system administrators to change the calculation to compute the award amount using a value other than adjusted basic pay.
See: Award Actions, Oracle US Federal Human Resources Compensation and Benefits Management Guide
Miscellaneous Pay Adjustment (NOA 890)
You can use NOA 890 to process standard and AFHR employees. Using NOA, you can implement alternative personnel systems and move standard employees to AFHR positions. When moving employees to AFHR positions, you can also make appropriate changes in the RPA extra information. For example, you can change the person's Tenure, Appointment Type, Conversion to Career Due date, retirement plan, and Date Last Equivalent Increase.
See: Moving Employees to AFHR Positions
Apart from moving standard employees to AFHR positions, you can process the following actions using NOA 890:
Process adjustments in an employee's basic pay.
Terminate an employee's pay retention.
Move an employee from a GM pay plan to a GS pay plan.
Move an employee from a GS pay plan to WG pay plan.
Process an increase in the rate of pay for an employee who is on an ES pay plan.
Process higher rate of pay for an employee.
Group Adjustments (NOA 896)
You can use NOA 896 to recognize the contributions of a team by authorizing a group pay adjustment for all team members. You must process an RPA for each AFHR team member.
Pay Reduction (NOA 897)
If an AFHR employee's performance or conduct warrants a reduction in pay, you can process a reduction of pay within an existing pay range.
After OPM approves an alternative federal human resource system (AFHR), you can move employees affected by the change from their existing system to the new one. For example, you might move employees from a standard grade and step wage schedule to a system based on performance based schedules.
You identify the applicable personnel system in the position definition. The employee's assigned position then determines which business rules and calculations the application uses. To move employees from an existing system to a new system, complete the following steps.
Create a new position.
You cannot convert existing positions to AFHR positions. You must create new positions and then move employees into them.
See: Creating a Position, Oracle HRMS Enterprise and Workforce Management Guide
In the Position extra information, enter the Personnel System Indicator (PSI) in the US Federal Alt HR System flexfield.
Note: You do not have to enter information for standard positions. A PSI of null or 00 identifies the position as standard.
See: Creating a Position, Oracle HRMS Enterprise and Workforce Management Guide
Process and update an RPA to move the employee to the new position.
You can process a NOA 890 Miscellaneous Pay Adjustment to move employees to their new AFHR positions.
See: Processing an RPA