[Home] [Help]
991: and paf.pay_basis_id = ppb.pay_basis_id(+);
992:
993: -- 05/11/02 - Bug 2340234 Fix Begins
994: -- The following cursor was copied from
995: -- per_pay_proposals_populate.get_prev_salary procedure.
996: CURSOR lc_previous_pay IS
997: SELECT pro.proposed_salary_n
998: ,pro.change_date
999: FROM per_pay_proposals pro
1082:
1083: ln_old_fte_factor := per_saladmin_utility.get_fte_factor(p_assignment_id,
1084: p_effective_date);
1085:
1086: PER_PAY_PROPOSALS_POPULATE.GET_BASIS_DETAILS(p_effective_date => p_effective_date
1087: ,p_assignment_id => p_assignment_id
1088: ,p_currency => lv_tmp_currency
1089: ,p_salary_basis_name => lv_tmp_salary_basis_name
1090: ,p_pay_basis_name => lv_tmp_pay_basis_name
1442: THEN
1443: hr_utility.set_location(l_proc,125);
1444: -- If it is a change to a salary basis, we need to derive previous salary
1445: -- again. This is because in my_get_defaults which calls
1446: -- per_pay_proposals_populate.get_defaults, that procedure will set prev
1447: -- salary to null when the old and new salary basis's element type id is
1448: -- different. The Current Pay Rate region will show zero in the Salary
1449: -- and Annual Equivalent columns.
1450: -- This zapping of prev salary to null happens in
1447: -- salary to null when the old and new salary basis's element type id is
1448: -- different. The Current Pay Rate region will show zero in the Salary
1449: -- and Annual Equivalent columns.
1450: -- This zapping of prev salary to null happens in
1451: -- per_pay_proposals_populate.get_prev_salary procedure.
1452:
1453: OPEN lc_previous_pay;
1454: FETCH lc_previous_pay into ln_prev_salary2
1455: ,ld_last_change_date;
1458: IF ln_prev_salary is NULL and ln_prev_salary2 IS NOT NULL
1459: THEN
1460: hr_utility.set_location(l_proc,130);
1461: -- Element type id is changed because in the procedure
1462: -- per_pay_proposals_populate.get_prev_salary, it will zap the
1463: -- previous salary to null if element type id are not equal between
1464: -- the old and new salary basis.
1465: p_element_type_id_changed := 'Y';
1466: ln_prev_salary := ln_prev_salary2;
1617: AND pgr.effective_end_date;
1618:
1619: BEGIN
1620: hr_utility.set_location(' Entering:' || l_proc,5);
1621: per_pay_proposals_populate.get_defaults(
1622: p_assignment_id => p_assignment_id ,
1623: p_date => p_date,
1624: p_business_group_id => p_business_group_id,
1625: p_currency => p_currency,
4375: -- 04/24/02 Change Begins
4376: -- Always reset the previous salary and old annualization factor
4377: -- with the values passed in which were saved at the beginning of the
4378: -- procedure. The reason is that my_get_defaults will call
4379: -- per_pay_proposals_populate.get_defaults which will zap the
4380: -- previous salary to null if element_type_id is different
4381: -- between the old and the new.
4382: ltt_salary_data(1).default_prev_salary := ln_save_prev_salary;
4383: ltt_salary_data(1).default_pay_annual_factor :=ln_save_pay_annual_factor;
5323:
5324: hr_utility.set_location(l_proc,10);
5325: ln_transaction_step_id := p_transaction_step_id;
5326:
5327: PER_PAY_PROPOSALS_POPULATE.GET_BASIS_DETAILS(p_effective_date => hr_transaction_api.get_date_value
5328: (p_transaction_step_id => ln_transaction_step_id,
5329: p_name => 'p_effective_date')
5330: ,p_assignment_id => hr_transaction_api.get_number_value
5331: (p_transaction_step_id => ln_transaction_step_id,
6392: -- p_effective_date value or the WF effective date.
6393: ld_date := to_date(l_effective_date,
6394: hr_process_assignment_ss.g_date_format);
6395:
6396: PER_PAY_PROPOSALS_POPULATE.get_element_id
6397: (p_assignment_id => ltt_salary_data(1).assignment_id
6398: ,p_business_group_id => ltt_salary_data(1).business_group_id
6399: ,p_change_date => ld_date -- Bug 2360907 Fix
6400: ,p_payroll_value => ln_payroll_id