Queries to get the retropay setups for changes made in UDT and Global Value.

SOLUTION

1. Table Event Update

SELECT pdt.table_name
,peu.column_name
,hrl.meaning
,peu.change_type
,peu.business_group_id
,peu.legislation_code
FROM pay_event_updates peu
,pay_dated_tables pdt
,hr_lookups hrl
WHERE peu.dated_table_id = pdt.dated_table_id
AND pdt.table_name IN ('FF_GLOBALS_F','PAY_USER_COLUMN_INSTANCES_F')
AND peu.change_type IN ('DATE_EARNED','DATE_PROCESSED')
AND hrl.lookup_code = peu.event_type
AND hrl.lookup_type = 'EVENT_TYPE'
ORDER BY pdt.table_name;

2. Table Event Group

select pde.datetracked_event_id,
pde.event_group_id,
pdt.table_name,
pde.column_name,
hrl.meaning,
pde.business_group_id,
pde.legislation_code
from pay_datetracked_events pde,
pay_dated_tables pdt,
pay_event_groups peg,
hr_lookups hrl
where peg.event_group_name = '<EVENT_GROUP_NAME>'
and pde.event_group_id = peg.event_group_id
and pde.dated_table_id = pdt.dated_table_id
and hrl.lookup_code = pde.update_type
and hrl.lookup_type = 'UPDATE_TYPE'
order by pdt.table_name;

3. Process Events

SELECT ppe.process_event_id
,ppe.effective_date
,ppe.creation_date
,ppe.calculation_date
,ppe.assignment_id
,ppe.business_group_id
,pdt.table_name
,peu.column_name
,ppe.surrogate_key
,hrl.meaning
,peu.event_type
,peu.change_type
,ppe.description
FROM pay_process_events ppe
,pay_event_updates peu
,pay_dated_tables pdt
,hr_lookups hrl
WHERE ppe.assignment_id IS NULL
AND ppe.event_update_id = peu.event_update_id
AND peu.dated_table_id = pdt.dated_table_id
AND pdt.table_name in ('PAY_USER_COLUMN_INSTANCES_F','FF_GLOBALS_F')
AND hrl.lookup_code = peu.event_type
AND hrl.lookup_type = 'EVENT_TYPE'
AND peu.change_type IN('DATE_PROCESSED','DATE_EARNED')
ORDER BY ppe.last_update_date DESC;

5. Package pay_group_event_pkg

select line ||': '||text from dba_source where name = 'PAY_GROUP_EVENT_PKG'

and type = 'PACKAGE BODY';

6. User Defined Table

select t.user_table_name, t.range_or_match, c.user_column_name, row_low_range_or_name,

row_high_range, value
from pay_user_column_instances_f i,
pay_user_columns c,
pay_user_rows_f r,
pay_user_tables t
where i.user_column_id = c.user_column_id
and i.user_row_id = r.user_row_id
and c.user_table_id = t.user_table_id
and c.user_column_name = '<COLUMN_NAME>'
and t.user_table_name = '<UDT Name>'
order by i.user_column_instance_id;

7. Global Value

select global_id, effective_start_date, effective_end_date, global_name, global_value

from ff_globals_f
where global_name = '<GLOBAL_NAME>';

--------------XXXX---------------------XXXXX-----------------------XXXXX------------------------
Copyright (c) 2021, Oracle. All rights reserved. Oracle Confidential.

Troubleshooting Retropay: How to Use SQL to Find the Source of Retro To

Entries (Doc ID 2080545.1) Bottom

In this Document

Purpose

Troubleshooting Steps

Step 1: Examine the pay_process_events table

Step 2: Examine the pay_element_entries_f table

Step 3: Find the source of the retro entry

A. If the CREATOR_TYPE is 'EE'

B. If the CREATOR_TYPE is "RR'

References

APPLIES TO:

Oracle Payroll - Version 11.5.10.2 and later

Information in this document applies to any platform.

PURPOSE

Oftentimes, Retropay by Element or Retropay (Enhanced) creates one or more retro entries that
are unexpected and the user is unable to find an explanation for the creation of the entries.

This document is intended to provide information about using SQL queries to help find the
source of those entries. Attached is a document showing two examples of how this is
accomplished.

TROUBLESHOOTING STEPS

In most cases, retro entries are triggered by some event that takes place retroactively in the
payroll application. Events can be such things as inserting or updating an element entry,
updating an employee's salary, assignment changes, fast formula updates, and more. Each
business determines which events should trigger Retropay and sets up its environment based on
those requirements. Once this setup is complete, these events are captured in the
pay_process_events table. This is the first place to look for the source of retro entries.

For more information about Retropay event setup, please see My Oracle Support (MOS) Document ID
749141.1 - Troubleshoot RetroPay Setup

Sometimes, you can plainly see in the pay_process_events table the event that triggered
Retropay, but other times, it is not so clear and one must use the information there to trace back
through the pay_element_entries_f and pay_run_results tables to get to the source. In the steps
below, we will discuss the queries and what the results mean in terms of the Retropay entries.

STEP 1: EXAMINE THE PAY_PROCESS_EVENTS TABLE

Run the following query for the employee with the retro entry in question.

Note: You will need the assignment_id of the employee for each of the queries in this
document.

select
ppe.effective_date,ppe.creation_date,ppe.assignment_id,ppe.status,pdt.
table_name,peu.column_name,
ppe.surrogate_key,peu.event_type,peu.change_type,ppe.description,
petf.element_name
from pay_process_events ppe,pay_event_updates peu, pay_dated_tables
pdt, pay_element_types_f petf
where ppe.assignment_id = <assignment_id>
and peu.change_type in ('DATE_EARNED','DATE_PROCESSED')
and ppe.event_update_id = peu.event_update_id
and peu.dated_table_id = pdt.dated_table_id
and petf.element_type_id in (select petf.element_type_id from
pay_element_types_f petf,
pay_element_entries_f peef where ppe.surrogate_key =
peef.element_entry_id
and peef.element_type_id = petf.element_type_id)
order by ppe.creation_date desc;

This query returns all the events that have been logged for the assignment. The most relevant
information is:

Column Meaning

EFFECTIVE_DATE Effective date of the event

CREATION_DATE Date the event was created

TABLE_NAME Name of the table on which the event was triggered

COLUMN_NAME The column of the table on which the event was triggered

This is a unique value for each event (like element_entry_id for pay_element_entries_f table). Each tab
SURROGATE_KEY
Functionality Overview Frequently Asked Questions (FAQ)

EVENT_TYPE Indicates what kind of event took place, such as update, delete, insert.

CHANGE_TYPE Only DATE_EARNED and DATE_PROCESSED are considered for Retropay

DESCRIPTION Where appropriate, this will contain a brief explanation of the change that is made in an update.

ELEMENT_NAME When an event affects an element, the element name will be displayed here.

As mentioned earlier, it is sometimes easy to spot an event that caused Retropay to create
entries. For example, let's say that the business requires Retropay to be triggered whenever there
is a back-dated Grade change for an assignment. In that case, you would see an event with the
effective date of the change, table_name = PER_ALL_ASSIGNMENTS_F, and the
column_name = GRADE_ID. In the DESCRIPTION column, you may even see something like
'12 -> 34', indicating that the grade_id changed from '12' to '34'.

Other times, it is not so easy to see what caused a retro entry and you only see the insertion of the
entry in the pay_process_events table. In these cases, more investigation is needed into the
pay_element_entries_f table and sometimes, the pay_run_results table. In these cases, it's
important to make a note of the retro entry's SURROGATE_KEY as it will be needed in the
next steps.
STEP 2: EXAMINE THE PAY_ELEMENT_ENTRIES_F TABLE

The SURROGATE_KEY of the retro entry in the pay_process_events table is the

ELEMENT_ENTRY_ID as it comes from the pay_element_entries_f table. In this step, you will
examine the record(s) associated with the element_entry_id. Run this query for the same
assignment_id as in Step 1:

select distinct pet.element_name, pet.element_type_id, piv.name

Input_Value,
pee.element_entry_id, pee.creator_type, pee.entry_type,
pev.screen_entry_value, pev.effective_start_Date,
pev.effective_end_Date,pee.creator_id,
pee.source_id, pee.source_asg_action_id, pee.source_start_date,
pee.source_end_date
from pay_element_types_f pet,
pay_input_values_f piv,
pay_element_entries_f pee,
pay_element_entry_Values_f pev
where pee.assignment_id = <assignment_id>
and piv.element_type_id = pet.element_type_id
and pee.element_type_id = pet.element_type_id
and pee.element_entry_id = pev.element_Entry_id
and pev.input_value_id = piv.input_value_id
order by 1,6,5;

Suggestion: The results of this query show you all of the element entries for the assignment. Since this
can often return many rows, you may want to export the results to a spreadsheet so it is easy to filter on
only the needed data, or you can modify the query to return only the rows in which you're interested.
In that case, you would add a clause to return only the records with the element_entry_id that this the
same as the surrogate_key from the retro entry in Step 1.

Once you have the results, find the records that have the same element_entry_id as the retro
entry's surrogate_key value in the pay_process_events table. There will be a lot of relevant data,
but 2 columns are of particular interest: CREATOR_TYPE and SOURCE_ID.

The CREATOR_TYPE column will have one of 2 values, either 'EE' or 'RR'

 'EE' indicates the retro entry was created because there was an element entry either inserted or
deleted.
 'RR' indicates the retro entry was created because there was a variance between original run
results and the recalculated run results of an element entry.
The SOURCE_ID column will contain a value which is based on the CREATOR_TYPE

 If the CREATOR_TYPE is 'EE', the SOURCE_ID is the element_entry_id of the original (parent)
element.
 If the CREATOR_TYPE is 'RR', the SOURCE_ID is the run_result_id of the run results of the
original (parent) element.

The next steps in the investigation differ, depending on whether the CREATOR_TYPE is 'EE' or
'RR'. In either case, make a note of the SOURCE_ID value for use in the next steps.

STEP 3: FIND THE SOURCE OF THE RETRO ENTRY

A. If the CREATOR_TYPE is 'EE'

If the CREATOR_TYPE in Step 2 is 'EE', then the SOURCE_ID indicates the

ELEMENT_ENTRY_ID of the element entry that is the source of the retro entry. In this case,
you would return to the results of the query in Step 2 and find the record(s) with that
ELEMENT_ENTRY_ID value. This is the source of the retro entry and you will be able to see
all the relevant information about that entry. At this point, the investigation is complete.

To see an example of this scenario, please see Example 1 in the attached document: Retropay
Troubleshooting

B. If the CREATOR_TYPE is "RR'

If the CREATOR_TYPE in Step 2 is 'RR', then the SOURCE_ID indicates the

RUN_RESULT_ID of the run result that has a variance from the original payroll action results.
To investigate this, you will need to run a query to get the assignment's run results from the
PAY_RUN_RESULTS table.

select distinct
pet.element_name,piv.name,ppa.action_type,ppa.effective_date
payroll_run_date,prr.run_result_id,prv.result_value,prr.entry_type,
prr.source_id, prr.source_type,prr.start_date, prr.end_date,
prr.element_entry_id, prv.formula_result_flag
from pay_element_types_f pet,
pay_input_values_f piv,
pay_run_results prr,
pay_run_result_Values prv,
pay_assignment_actions paa,
pay_payroll_actions ppa
where paa.assignment_id = <assignment_id>
and paa.payroll_action_id = ppa.payroll_action_id
and paa.assignment_action_id = prr.assignment_action_id
and prr.run_result_id = prv.run_Result_id
and prv.input_value_id = piv.input_value_id
and pet.element_type_id = prr.element_type_id
and piv.element_type_id = pet.element_type_id
and ppa.action_type in ('Q','R','V','B')
order by 1,2,3,4,9,10;

From the results of this query, you will find the record(s) associated with the RUN_RESULT_ID
indicated by the SOURCE_ID value in Step 2. The most relevant information is:

Column Meaning

ELEMENT_NAME Name of the original element that is the source of the retro entry

NAME Name of Input Values for the element

This code indicates the pay action type that produced the run results.

 'Q' - Quick Pay

ACTION_TYPE  'R' - Payroll Run
 'B' - Balance Adjustment
 'V' - Reversal

PAYROLL_RUN_DATE Payroll period of the payroll action

RESULT_VALUE Original run result value. This is what Retropay is comparing against when re

These values indicate the ELEMENT_ENTRY_ID of the original element entry t

SOURCE_ID and ELEMENT_ENTRY_ID If the values are not the same, then there is a data corruption issue that can b
MOS Note 2026653.1 - Retropay Creates Unexpected Entries When No Chan

Once you have found the relevant run results, make a note of the RESULT_VALUE for each
input value, and the SOURCE_ID value.

Now go back to the query results from Step 2 and find the record(s) associated with the
SOURCE_ID. This will show you all the current data (such as input values) for the element
entry. You can compare the original run results values with the current element entry input
values and see from where the retro entry values are coming.

To see an example of this scenario, please see Example 2 in the attached document: Retropay
Troubleshooting

NOTE: In the images below and/or the attached document, user details / company name /
address / email / telephone number represent a fictitious sample (based upon made up data used
in the Oracle Demo Vision instance). Any similarity to actual persons, living or dead, is purely
coincidental and not intended in any manner.