1 package body PER_ABSENCE_ATTENDANCES_PKG2 as
2 /* $Header: peaba02t.pkb 115.3 2002/12/11 12:17:33 raranjan ship $ */
3
4 --this procedure was written as a workaround. For some reason the
5 --hr_entry_api procedure cannot be directly called from the form
6 --therefore requiring that this server side procedure be written as
7 --an interface between the two. The problem seems to be the interfacing
8 --between forms and the server side code. It could be the differing
9 --versions of PLSQL in use between forms and the server, the large number of
10 --variables in use or the overloading of the package headers.
11
12 procedure insert_element(p_effective_start_date IN OUT NOCOPY DATE,
13 p_effective_end_date IN OUT NOCOPY DATE,
14 p_element_entry_id IN OUT NOCOPY NUMBER,
15 p_assignment_id In NUMBER,
16 p_element_link_id IN NUMBER,
17 p_creator_id IN NUMBER,
18 p_creator_type IN VARCHAR2,
19 p_entry_type IN VARCHAR2,
20 p_input_value_id1 IN NUMBER,
21 p_entry_value1 IN VARCHAR2) is
22 --
23 -- local vars being used so values not passed back to the client
24 -- they are incorrect. KLS 13/7/95 WWbug 269609
25 --
26 l_eff_start_date date;
27 l_eff_end_date date;
28 l_element_type_id number;
29 l_element_link_id number;
30
31 cursor c_get_element_type is
32 select distinct pel.element_type_id
33 from pay_element_links_f pel
34 where pel.element_link_id = p_element_link_id
35 and p_effective_start_date between pel.effective_start_date
36 and pel.effective_end_date;
37
38
39 begin
40
41 l_eff_start_date := p_effective_start_date;
42 l_eff_end_date := p_effective_end_date;
43
44 --
45 -- Bug 1806161. Re-obtain the element_link_id because the form can
46 -- get the incorrect link under certain circumstances. First get the
47 -- element type.
48 --
49 open c_get_element_type;
50 fetch c_get_element_type into l_element_type_id;
51 close c_get_element_type;
52
53 l_element_link_id := hr_entry_api.get_link
54 (p_assignment_id => p_assignment_id
55 ,p_element_type_id => l_element_type_id
56 ,p_session_date => l_eff_start_date);
57
58 hr_entry_api.insert_element_entry(p_effective_start_date => l_eff_start_date,
59 p_effective_end_date => l_eff_end_date,
60 p_element_entry_id => p_element_entry_id,
61 p_assignment_id => p_assignment_id,
62 p_element_link_id => l_element_link_id,
63 p_creator_id => p_creator_id,
64 p_creator_type => p_creator_type,
65 p_entry_type => p_entry_type,
66 p_input_value_id1 => p_input_value_id1,
67 p_entry_value1 => p_entry_value1);
68 end insert_element;
69
70
71
72 --this procedure was written as a workaround. For some reason the
73 --hr_entry_api procedure cannot be directly called from the form
74 --therefore requiring that this server side procedure be written as
75 --an interface between the two. The problem seems to be the interfacing
76 --between forms and the server side code. It could be the differing
77 --versions of PLSQL in use between forms and the server, the large number of
78 --variables in use or the overloading of the package headers.
79
80 procedure update_element(p_dt_update_mode IN VARCHAR2,
81 p_session_date IN DATE,
82 p_element_entry_id IN NUMBER,
83 p_creator_id IN NUMBER,
84 p_creator_type IN VARCHAR2,
85 p_input_value_id1 IN NUMBER,
86 p_entry_value1 IN VARCHAR2) is
87
88 begin
89 hr_entry_api.update_element_entry(p_dt_update_mode => p_dt_update_mode,
90 p_session_date => p_session_date,
91 p_element_entry_id =>
92 p_element_entry_id,
93 p_creator_id => p_creator_id,
94 p_creator_type => p_creator_type,
95 p_input_value_id1 =>
96 p_input_value_id1,
97 p_entry_value1 => p_entry_value1);
98 end update_element;
99
100
101 end PER_ABSENCE_ATTENDANCES_PKG2;