eTRM uses javascript that opens and focuses a separate window to display reports. Your browser does not appear to support javascript. This should not prevent you from using eTRM but it does mean the window focus feature will not work. Please check the contents of other windows on your desktop if you click on a link that does not appear to do anything.

APPS.HR_PAY_RATE_SS dependencies on PER_PAY_PROPOSALS

Line 453: From per_pay_proposals pp, per_assignments_f paf,

449: ln_last_pay2 NUMBER ;
450:
451: CURSOR c_last_pay IS
452: Select pp.proposed_salary_n*pay_annualization_factor
453: From per_pay_proposals pp, per_assignments_f paf,
454: per_pay_bases ppb
455: Where pp.assignment_id = p_assignment_id
456: And pp.business_group_id = p_bus_group_id
457: And pp.approved = 'Y'

Line 950: ln_pay_proposal_id per_pay_proposals.pay_proposal_id%type ;

946: lv_last_pay_change varchar2(200) default null;
947: lv_flsa_status hr_lookups.meaning%type default null;
948: lv_currency_symbol fnd_currencies.symbol%type default null;
949: ln_precision number default null;
950: ln_pay_proposal_id per_pay_proposals.pay_proposal_id%type ;
951: ln_current_salary number default null;
952: ln_proposal_ovn per_pay_proposals.object_version_number%type;
953: lv_api_mode varchar2(30) default null;
954: ld_get_defaults_date date default null;

Line 952: ln_proposal_ovn per_pay_proposals.object_version_number%type;

948: lv_currency_symbol fnd_currencies.symbol%type default null;
949: ln_precision number default null;
950: ln_pay_proposal_id per_pay_proposals.pay_proposal_id%type ;
951: ln_current_salary number default null;
952: ln_proposal_ovn per_pay_proposals.object_version_number%type;
953: lv_api_mode varchar2(30) default null;
954: ld_get_defaults_date date default null;
955: lv_warning_message varchar2(4000) default '';
956: ln_old_pay_annual_factor number default null;

Line 987: -- per_pay_proposals_populate.get_prev_salary procedure.

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

Line 991: FROM per_pay_proposals pro

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
992: WHERE pro.assignment_id = p_assignment_id
993: AND pro.change_date =(select max(pro2.change_date)
994: from per_pay_proposals pro2
995: where pro2.assignment_id = p_assignment_id

Line 994: from per_pay_proposals pro2

990: ,pro.change_date
991: FROM per_pay_proposals pro
992: WHERE pro.assignment_id = p_assignment_id
993: AND pro.change_date =(select max(pro2.change_date)
994: from per_pay_proposals pro2
995: where pro2.assignment_id = p_assignment_id
996: and pro2.change_date < p_effective_date);
997: -- 05/11/02 - Bug 2340234 Fix Begins
998:

Line 1060: PER_PAY_PROPOSALS_POPULATE.GET_BASIS_DETAILS(p_effective_date => p_effective_date

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

Line 1399: -- per_pay_proposals_populate.get_defaults, that procedure will set prev

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

Line 1404: -- per_pay_proposals_populate.get_prev_salary procedure.

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;

Line 1415: -- per_pay_proposals_populate.get_prev_salary, it will zap the

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;

Line 1546: per_pay_proposals_populate.get_defaults(

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,

Line 1960: from PER_PAY_PROPOSALS

1956: approved,
1957: review_date,
1958: multiple_components,
1959: object_version_number
1960: from PER_PAY_PROPOSALS
1961: Where assignment_id = p_assignment_id
1962: AND business_group_id = p_bg_id
1963: order by change_date desc ;
1964:

Line 2126: from PER_PAY_PROPOSALS

2122: approved,
2123: review_date,
2124: multiple_components,
2125: object_version_number
2126: from PER_PAY_PROPOSALS
2127: Where assignment_id = p_assignment_id
2128: AND business_group_id = p_bg_id
2129: order by change_date desc ;
2130:

Line 4218: -- per_pay_proposals_populate.get_defaults which will zap the

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;

Line 5164: PER_PAY_PROPOSALS_POPULATE.GET_BASIS_DETAILS(p_effective_date => hr_transaction_api.get_date_value

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,

Line 6094: PER_PAY_PROPOSALS_POPULATE.get_element_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

Line 6252: per_pay_proposals pay,

6248: pay.proposed_salary_n,
6249: pb.name
6250: from
6251: per_all_assignments_f asf,
6252: per_pay_proposals pay,
6253: per_pay_bases pb,
6254: pay_input_values_f pv
6255: where asf.person_id = p_person_id
6256: and asf.assignment_type = 'O'