[Home] [Help]
983: and paf.pay_basis_id = ppb.pay_basis_id(+);
984:
985: -- 05/11/02 - Bug 2340234 Fix Begins
986: -- The following cursor was copied from
987: -- per_pay_proposals_populate.get_prev_salary procedure.
988: CURSOR lc_previous_pay IS
989: SELECT pro.proposed_salary_n
990: ,pro.change_date
991: FROM per_pay_proposals pro
1056: ,lv_old_salary_basis_name
1057: ,ln_old_pay_annual_factor;
1058: CLOSE lc_get_curr_asg_pay_basis_id;
1059:
1060: PER_PAY_PROPOSALS_POPULATE.GET_BASIS_DETAILS(p_effective_date => p_effective_date
1061: ,p_assignment_id => p_assignment_id
1062: ,p_currency => lv_tmp_currency
1063: ,p_salary_basis_name => lv_tmp_salary_basis_name
1064: ,p_pay_basis_name => lv_tmp_pay_basis_name
1395: THEN
1396: hr_utility.set_location(l_proc,125);
1397: -- If it is a change to a salary basis, we need to derive previous salary
1398: -- again. This is because in my_get_defaults which calls
1399: -- per_pay_proposals_populate.get_defaults, that procedure will set prev
1400: -- salary to null when the old and new salary basis's element type id is
1401: -- different. The Current Pay Rate region will show zero in the Salary
1402: -- and Annual Equivalent columns.
1403: -- This zapping of prev salary to null happens in
1400: -- salary to null when the old and new salary basis's element type id is
1401: -- different. The Current Pay Rate region will show zero in the Salary
1402: -- and Annual Equivalent columns.
1403: -- This zapping of prev salary to null happens in
1404: -- per_pay_proposals_populate.get_prev_salary procedure.
1405:
1406: OPEN lc_previous_pay;
1407: FETCH lc_previous_pay into ln_prev_salary2
1408: ,ld_last_change_date;
1411: IF ln_prev_salary is NULL and ln_prev_salary2 IS NOT NULL
1412: THEN
1413: hr_utility.set_location(l_proc,130);
1414: -- Element type id is changed because in the procedure
1415: -- per_pay_proposals_populate.get_prev_salary, it will zap the
1416: -- previous salary to null if element type id are not equal between
1417: -- the old and new salary basis.
1418: p_element_type_id_changed := 'Y';
1419: ln_prev_salary := ln_prev_salary2;
1542:
1543:
1544: BEGIN
1545: hr_utility.set_location(' Entering:' || l_proc,5);
1546: per_pay_proposals_populate.get_defaults(
1547: p_assignment_id => p_assignment_id ,
1548: p_date => p_date,
1549: p_business_group_id => p_business_group_id,
1550: p_currency => p_currency,
4214: -- 04/24/02 Change Begins
4215: -- Always reset the previous salary and old annualization factor
4216: -- with the values passed in which were saved at the beginning of the
4217: -- procedure. The reason is that my_get_defaults will call
4218: -- per_pay_proposals_populate.get_defaults which will zap the
4219: -- previous salary to null if element_type_id is different
4220: -- between the old and the new.
4221: ltt_salary_data(1).default_prev_salary := ln_save_prev_salary;
4222: ltt_salary_data(1).default_pay_annual_factor :=ln_save_pay_annual_factor;
5160:
5161: hr_utility.set_location(l_proc,10);
5162: ln_transaction_step_id := p_transaction_step_id;
5163:
5164: PER_PAY_PROPOSALS_POPULATE.GET_BASIS_DETAILS(p_effective_date => hr_transaction_api.get_date_value
5165: (p_transaction_step_id => ln_transaction_step_id,
5166: p_name => 'p_effective_date')
5167: ,p_assignment_id => hr_transaction_api.get_number_value
5168: (p_transaction_step_id => ln_transaction_step_id,
6090: -- p_effective_date value or the WF effective date.
6091: ld_date := to_date(l_effective_date,
6092: hr_process_assignment_ss.g_date_format);
6093:
6094: PER_PAY_PROPOSALS_POPULATE.get_element_id
6095: (p_assignment_id => ltt_salary_data(1).assignment_id
6096: ,p_business_group_id => ltt_salary_data(1).business_group_id
6097: ,p_change_date => ld_date -- Bug 2360907 Fix
6098: ,p_payroll_value => ln_payroll_id