Oracle Payroll 'RetroPay Functionality Overview' Frequently Asked Questions (FAQ) [ID 877282.

1]
Modified:Dec Priority:2

To Bottom

20, 2012

Type:FAQ

Status:PUBLISHED

Comments (0)

In this Document Purpose Questions and Answers What is RetroPay? What is RetroPay by Aggregate? What is RetroPay by Element? What is RetroPay Enhanced? Why use RetroPay Enhanced? Retro Changes (Correction vs Back-Dated) What are the steps to process RetroPay (Enhanced)? What is the role of 'Events'? What is the check-list for 'Event' logging? What is the purpose of 'Reprocess Type'? What is the purpose of 'Recorded Date'? What is the purpose of the Retro-Notification Report? What is the purpose of the 'Retro Status' page? What is the function of the 'RetroPay (Enhanced)' program? What is 'Back Pay Adjustment' functionality? What is 'Retro Overlap' functionality? How to enabled 'RetroPay Overlap' functionality? Is there a way to know what legislation's/localizations support RetroPay? Community Discussions Feedback References

Applies to:
Oracle Payroll Information in this document applies to any platform.

Purpose

Document provides a Frequently Asked Question (FAQ) on RetroPay Functionality at an 'Overview' level.

Questions and Answers What is RetroPay?

Retro pay allows users to recalculate past payroll runs comparing the previous results with the new results. If any changes are detected they are applied to the current period. These deltas are then taken into account in the next payroll run. It can be broadly classified as:

RetroPay by Aggregate RetroPay by Element RetroPay Enhanced

All the above will re-run the past payroll runs and compare the previous results with the new ones. Difference occurs in creation of new entries.

What is RetroPay by Aggregate?

RetroPay by Aggregate will sum up all the changes and create one entry with the given value. Even if the payroll run span across periods, it will aggregate all the changes and create only one entry. It will be difficult in identifying for which period the change happened and for which components (Basic salary, Overtime payments, Bonus payments etc.) In later version, RetroPay by Aggregate creates one entry for each period. Users can then relate the changes with the corresponding period(s).

What is RetroPay by Element?

RetroPay by Element program will identify the changes, element wise and creates new entries for each element. It will create new entries (with the same element name) and add those values. This had some initial problems in reporting (payslip, SOE etc.) and other post-processing like pension calculation etc. Although, provisions have been made so new elements are attached as retro element for each element. Extra values will be added to the retro elements. In later version, provisions were also made to include assignment and element set(s). The RetroPay program will pick the assignments based on the given assignment set. It will also create extra entries based on the elements given in the element set ( i.e., If an element is not present in the given element set, even though it has to create a new entry for the given element it will omit the process).

What is RetroPay Enhanced?

Users need to identify the lists of assignments and include those for retro pay calculation. The RetroPay Enhanced program automates this process. The functionality will automatically identify the lists of assignments and runs the retro. Event logging mechanism is used for

identifying the list of assignments. A separate program (Retro-Notification Report) will use these events, identify the assignments, and add those in a separate table. The RetroPay Enhanced program will retrieve the assignments from this table. Users are only required to make the retro changes and the application will automatically process those assignments. In later version's, the RetroPay By Element process was further expanded. Users will define some components (Primary reason for change. This explains how the entry is directly recalculated). For each component, they can define a retro element based on the time periods. One component can have more than one time period with its corresponding retro element. The RetroPay program will pick the default component, identify the particular retro element and add the extra value. The assignment identification process was automated with more control in stopping and adding new assignments for retro processing. There may be situation, where customer would like to run the retro for a particular assignment in the later runs or include a new assignment for retro processing. A new self-service page - Retro Status - was introduced for this purpose.

Why use RetroPay Enhanced?

Retro pay program is an automated process. It identifies the assignments that are eligible for retro calculation and pick only those assignments. This helps users from manually identifying the assignments for retro calculation. Retro elements will be defined based on components and time period. Users can have different retro element for different scenarios With Enhanced Retropay, the concept of a retro assignment has now been introduced, providing an individual start date for each assignment. Unnecessary recalculation of periods prior to a change has now been eliminated. Using Retro Status page, user can block, add new assignments for retro processing. This makes the process more enhanced and user controllable.

Retro Changes (Correction vs Back-Dated)

A distinction has now been made between a corrective change (eg. required when information has been wrongly entered) and a deliberate backdated change (eg. a back dated pay award). These different types of changes may require different results being produced depending on statutory rules. The Enhanced RetroPay solution will address this For example:

Corrections may be taxed in the original earning period Back dated changes may be taxed in the period in which they are paid

What are the steps to process RetroPay (Enhanced)?

1. Make the retrospective change(s) to an assignment as required 2. Run the 'Retro-Notifications Report (Enhanced)' 3. Navigate to the View RetroPay Status window and make sure that the retro assignments and corresponding entries are created properly 4. Change individual entries where 'Recalculation Reason' is different from default 5. Run the 'RetroPay (Enhanced)' process and verify the element entries are created

What is the role of 'Events'?

Event logging mechanism plays an important role in identifying the assignment for retro calculation. Continuous calculation process uses event for it's processing and now it has been extended for retro pay. Any transaction (i.e. 'Event') that occurs in the system will be recorded. The RetroPay process will identify the assignments based on these events. Any change, such as: payroll name, assignment category, element entry updates, new element entries, salary basis, grade, formula etc. is called a trigger point. Users will create an event group by combining some of the trigger points. Based on these changes, assignments will be picked up for retro calculation.

What is the check-list for 'Event' logging?

Table Event Update Form: Open the Table Event Update form and query the required table. It will show the lists of changes for which an event will be logged. For payroll related process like pro-ration, continuous calculation and retro pay, the CHANGE_TYPE column needs to be defined as either DATE_EARNED or DATE_PROCESSED. So, please ensure that the required events have been defined correspondingly. If there any no events defined with those change_types for the required columns, they will need to be added. Also, please ensure that the proper event_types have been used in defining the events. For a table that doesn't have an API, the events available will be the basic database events of I, U and D. For tables that have APIs, all the datetrack events will be available. The different event_types are: Event Type I U D Meaning Insert Update Delete

INSERT UPDATE

Datetrack Insert Datetrack Update Datetrack Update Change UPDATE_CHANGE_INSERT Insert UPDATE_OVERRIDE Datetrack Update Override CORRECTION Datetrack Correction DELETE Datetrack End Date Datetracked Delete Next DELETE_NEXT_CHANGE Change Datetrack Delete Future FUTURE_CHANGE Changes ZAP Datetrack Purge Dynamic Trigger Form: Click the 'Triggers' button from the 'Table Event Updates' form. This will open the 'Dynamic Trigger' form. Check that the Insert, Update and Delete triggers are available with the generated and enabled flags checked. If any of the dynamic triggers are not generated or enabled, check both the 'Generated' and 'Enabled' check boxes. Save the form and re-query to confirm. Functional Area Form: Open the 'Functional Area Maintenance' form and query for 'INCIDENT REGISTER' functional area. Check the given dynamic triggers are included in trigger section. Open legislation and business group tabs and check the given legislation and business group are included. If all the above setups are done correctly, changes made to the table should be logged in the pay_process_events table. Make a change to that table and query pay_process_events to check if the event got logged. The pay_process_events table will have a column called Surrogate_key. This will contain a unique value for each change (like element_entry_id for pay_element_entries_f table). Users can query pay_process_events table using this column values. Table Name Pay_element_types_f Pay_element_links_f Pay_element_entries_f Pay_element_entry_values_f Pay_input_values_f Ff_globals_f Pay_all_payrolls_f Surrogate Key Element_type_id Element_link_id Element_entry_id Element_entry_value_id Input_value_id Global_id Payroll_id

Pay_cost_allocations_f Pay_grade_rules_f Pay_link_input_values_f Pay_user_column_instances_f Per_addresses Per_all_assignments_f Per_all_people_f Per_assignment_budget_values_f Per_contracts_f Per_pay_proposals Per_performance_reviews Per_periods_of_service Pay_personal_payment_methods_f Per_spinal_point_placements_f Pqh_rate_matrix_rates_f

Cost_allocation_id Grade_rule_id Link_input_value_id User_column_instance_id Address_id Assignment_id Person_id Assignment_budget_value_id Contract_id Pay_proposal_id Performance_review_id Period_of_service_id Personal_payment_method_id Placement_id Rate_matrix_rate_id

What is the purpose of 'Reprocess Type'?

The 'Reprocess Type' indicates how the element is to be processed within RetroPay. Reprocess: A full reprocess of all changed entries Static: RetroPay will not process any changes to the element when running the relevant component. The original run result values and indirect results for the entry will be used. Partial: This is very similar to Static, except that only the indirect results are recalculated.

What is the purpose of 'Recorded Date'?

Recorded date will be present for each assignment, for which the Retro-Notification report is run at least once. The last report run date is stored as 'recorded_date' in the pay_recorded_requests table. The Retro-Notification report checks for the events logged since the last report run and picks up those events as changes in the report output. This will ensure that the same event is not picked twice by Retro-Notification report.

What is the purpose of the Retro-Notification Report?

The Retro-Notification report identifies the assignments for retro calculation and will place it into the pay_retro_assignments and pay_retro_entries tables. Based on the event group (given by the user) and the last report run date for each assignment, the report will pick all the events present in pay_process_events table, validate those events, identify the eligible assignments for retro processing and add those assignments in pay_retro_assignments table. The process will also identify the element entry changes and add those in pay_retro_entries table. Element should have one default retro component. Elements that don't have a retro component will not be included in pay_retro_entries table.

What is the purpose of the 'Retro Status' page?

The Retro-Notification report will pick all the assignments that are eligible for retro. There may be chances that new assignment needs to be added in the list or even existing assignments which should be deferred for next retro run. In such scenarios, users can use the 'Retro Status' page for performing the above actions. For eg. Customers would have accidentally disabled dynamic triggers. In such scenario retro notification report will not identify the assignments and customer needs to manually add those.

What is the function of the 'RetroPay (Enhanced)' program?

The RetroPay (Enhanced) program will pick up the assignments from pay_retro_assignments table. It first obtains the list of payroll periods, for which payroll has to be re-run. Then it reruns the payroll for each period (as it is run at that time) and compares the original and new results. If there are any changes, it will create element entries in the current period. It will also check for back pay adjustment values and create entries accordingly. Once the program completes successfully, it will enter the assignment action id into the pay_retro_assignments table.

What is 'Back Pay Adjustment' functionality?

After assignment level modifications are made and RetroPay is executed, it is determined that the modification need to be nullified (updated with the old value). When RetroPay is executed again, there will be no change as the entry got reverted. But an extra entry already exists in the current payroll period. That will be reverted using back pay adjustment functionality.

What is 'Retro Overlap' functionality?

RetroPay recalculates payroll runs, balance adjustments, and reversals from a particular date onwards, this is called the 'start date' of the recalculations. However, when the 'start date' of a RetroPay for an assignment overlaps another effective/process date of a RetroPay, this 'start date' is reset to the earliest 'start date' of the RetroPay processes and the RetroPay process recalculates from the earlier date. In this case, 'an overlap' is detected and a 'Overlapping RetroPay' process occurs. For more information about this functionality, see Document 842307.1 RetroPay Overlap - A Technical White Paper

How to enabled 'RetroPay Overlap' functionality?

For detailed information on steps to enable the 'RetroPay Overlap' functionality see Document 842307.1 RetroPay Overlap - A Technical White Paper . This document will provide the necessary information to verify that RetroPay (Enhanced) functionality has already been enabled and will provide the steps to enable the 'RetroPay Overlap' functionality.

Is there a way to know what legislation's/localizations support RetroPay?

Refer to Document 1118267.1 What Localizations Support 'RetroPay By Element' and RetroPay Enhanced This document provides a matrix which shows which Localizations/Legislation's are supported for which RetroPay process ( RetroPay by Element , RetroPay Enhanced) for which application versions.

Community Discussions
Still have questions? Use the live My Oracle Support Payroll Community window below, to search for similar discussions or start a new discussion on this subject.

Feedback
To provide feedback on this note, click on the Rate this document link.

References
NOTE:1118267.1 - What Localizations Support 'Retropay By Element' and Retropay Enhanced NOTE:842307.1 - RetroPay Overlap - A Technical White Paper