DBA Data[Home] [Help]

PACKAGE BODY: APPS.PER_ABSENCE_ATTENDANCES_PKG2

Source


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;