DBA Data[Home] [Help]

APPS.PAY_RETRO_PKG dependencies on HR_API

Line 939: , p_system_reprocess_date IN DATE default hr_api.g_eot)

935: , p_reprocess_date IN DATE
936: , p_eff_date IN DATE
937: , p_retro_component_id IN NUMBER
938: , p_owner_type IN VARCHAR2 default 'S' --System
939: , p_system_reprocess_date IN DATE default hr_api.g_eot)
940: is
941: l_min_reprocess_date date;
942: l_min_effective_date date;
943: l_min_sys_reprocess_date date;

Line 957: nvl(system_reprocess_date, hr_api.g_eot),

953: --
954: select reprocess_date,
955: effective_date,
956: owner_type,
957: nvl(system_reprocess_date, hr_api.g_eot),
958: retro_component_id
959: into l_min_reprocess_date,
960: l_min_effective_date,
961: l_owner_type,

Line 2013: if (l_rec_date = hr_api.g_sot OR

2009: Otherwise, Balance Adjustments will be used till the reprocess_date and recalculations can be done from the reprocess_date.
2010: v_recorded_date is the date from which full recalculations are done. This is stored in serial_number column of
2011: pay_assignment_actions and can be queried after the retropay run to verify the recalculation_date used by the process.
2012: */
2013: if (l_rec_date = hr_api.g_sot OR
2014: p_adj_start_date < l_rec_date) THEN
2015: --
2016: hr_utility.set_location('process_recorded_date', 20);
2017:

Line 2103: and recorded_date is not equal to start of time (hr_api.g_sot) .

2099: /* Added to_char for l_assign_id in the following
2100: two queries for fixing Bug:6893208 */
2101: /* Bug 8790029
2102: Case : Label_identifier in pay_assignment_actions was populated in process_recorded_date only when we are changing the recorded_date
2103: and recorded_date is not equal to start of time (hr_api.g_sot) .
2104: If the Overlap date comes after recorded_date label_identifier was not populated .
2105:
2106: After enabling retro_overlap ,Whenever retropay is rolled back , row from pay_recorded_requests for Retro_Overlap
2107: was getting deleted .This was because label_identifier in pay_assignment_actions was populated as null for Retro assignment action.

Line 2111: Fix : Modified pay_recorded_requests and removed the check "if (l_date <> hr_api.g_sot)" before updating label_identifier

2107: was getting deleted .This was because label_identifier in pay_assignment_actions was populated as null for Retro assignment action.
2108:
2109: This issue causes retro to run payrolls from overlap start date as there is no record in pay_recorded_requests for RETRO_OVERLAP.
2110:
2111: Fix : Modified pay_recorded_requests and removed the check "if (l_date <> hr_api.g_sot)" before updating label_identifier
2112: Start of time will get populated the first time reropay is run after Retro_Overlap feature is enabled
2113:
2114: Modified reset_recorded_request ,delete the 'RETRO_OVERLAP' row from pay_recorded_requests only when
2115: label_identifier is equal to start of time .

Line 2119: if (l_prev_rec_date = hr_api.g_sot)

2115: label_identifier is equal to start of time .
2116: If above is not the case update recorded_date only when label_identifier is not null .
2117: */
2118:
2119: if (l_prev_rec_date = hr_api.g_sot)
2120: then
2121: delete from pay_recorded_requests
2122: where ATTRIBUTE_CATEGORY = 'RETRO_OVERLAP'
2123: and ATTRIBUTE1 =to_char(l_assign_id);