1 Package ben_beo_shd AUTHID CURRENT_USER as
2 /* $Header: bebeorhi.pkh 120.0.12010000.1 2008/07/29 10:54:56 appldev ship $ */
3 --
4 -- ----------------------------------------------------------------------------
5 -- | Global Record Type Specification |
6 -- ----------------------------------------------------------------------------
7 --
8 Type g_rec_type Is Record
9 (elig_obj_id number
10 ,effective_start_date date
11 ,effective_end_date date
12 ,table_name varchar2(30)
13 ,column_name varchar2(30)
14 ,column_value varchar2(30)
15 ,business_group_id number
16 ,object_version_number number
17 );
18 --
19 -- ----------------------------------------------------------------------------
20 -- | Global Definitions - Internal Development Use Only |
21 -- ----------------------------------------------------------------------------
22 --
23 g_old_rec g_rec_type; -- Global record definition
24 -- Global table name
25 g_tab_nam constant varchar2(30) := 'BEN_ELIG_OBJ_F';
26 --
27 -- ----------------------------------------------------------------------------
28 -- |---------------------------< constraint_error >---------------------------|
29 -- ----------------------------------------------------------------------------
30 -- {Start Of Comments}
31 --
32 -- Description:
33 -- This procedure is called when a constraint has been violated (i.e.
34 -- The exception hr_api.check_integrity_violated,
35 -- hr_api.parent_integrity_violated, hr_api.child_integrity_violated or
36 -- hr_api.unique_integrity_violated has been raised).
37 -- The exceptions can only be raised as follows:
38 -- 1) A check constraint can only be violated during an INSERT or UPDATE
39 -- dml operation.
40 -- 2) A parent integrity constraint can only be violated during an
41 -- INSERT or UPDATE dml operation.
42 -- 3) A child integrity constraint can only be violated during an
43 -- DELETE dml operation.
44 -- 4) A unique integrity constraint can only be violated during INSERT or
45 -- UPDATE dml operation.
46 --
47 -- Prerequisites:
48 -- 1) Either hr_api.check_integrity_violated,
49 -- hr_api.parent_integrity_violated, hr_api.child_integrity_violated or
50 -- hr_api.unique_integrity_violated has been raised with the subsequent
51 -- stripping of the constraint name from the generated error message
52 -- text.
53 -- 2) Standalone validation test which corresponds with a constraint error.
54 --
55 -- In Parameter:
56 -- p_constraint_name is in upper format and is just the constraint name
57 -- (e.g. not prefixed by brackets, schema owner etc).
58 --
59 -- Post Success:
60 -- Development dependant.
61 --
62 -- Post Failure:
63 -- Developement dependant.
64 --
65 -- Developer Implementation Notes:
66 -- For each constraint being checked the hr system package failure message
67 -- has been generated as a template only. These system error messages should
68 -- be modified as required (i.e. change the system failure message to a user
69 -- friendly defined error message).
70 --
71 -- Access Status:
72 -- Internal Development Use Only.
73 --
74 -- {End Of Comments}
75 -- ----------------------------------------------------------------------------
76 Procedure constraint_error
77 (p_constraint_name in all_constraints.constraint_name%TYPE);
78 --
79 -- ----------------------------------------------------------------------------
80 -- |-----------------------------< api_updating >-----------------------------|
81 -- ----------------------------------------------------------------------------
82 -- {Start Of Comments}
83 --
84 -- Description:
85 -- This function is used to populate the g_old_rec record with the
86 -- current row from the database for the specified primary key
87 -- provided that the primary key exists and is valid and does not
88 -- already match the current g_old_rec. The function will always return
89 -- a TRUE value if the g_old_rec is populated with the current row.
90 -- A FALSE value will be returned if all of the primary key arguments
91 -- are null.
92 --
93 -- Prerequisites:
94 -- None.
95 --
96 -- In Parameters:
97 --
98 -- Post Success:
99 -- A value of TRUE will be returned indiciating that the g_old_rec
100 -- is current.
101 -- A value of FALSE will be returned if all of the primary key arguments
102 -- have a null value (this indicates that the row has not be inserted into
103 -- the Schema), and therefore could never have a corresponding row.
104 --
105 -- Post Failure:
106 -- A failure can only occur under two circumstances:
107 -- 1) The primary key is invalid (i.e. a row does not exist for the
108 -- specified primary key values).
109 -- 2) If an object_version_number exists but is NOT the same as the current
110 -- g_old_rec value.
111 --
112 -- Developer Implementation Notes:
113 -- None.
114 --
115 -- Access Status:
116 -- Internal Development Use Only.
117 --
118 -- {End Of Comments}
119 -- ----------------------------------------------------------------------------
120 Function api_updating
121 (p_effective_date in date
122 ,p_elig_obj_id in number
123 ,p_object_version_number in number
124 ) Return Boolean;
125 --
126 -- ----------------------------------------------------------------------------
127 -- |---------------------------< find_dt_upd_modes >--------------------------|
128 -- ----------------------------------------------------------------------------
129 -- {Start Of Comments}
130 --
131 -- Description:
132 -- This procedure is used to determine what datetrack update modes are
133 -- allowed as of the effective date for this entity. The procedure will
134 -- return a corresponding Boolean value for each of the update modes
135 -- available where TRUE indicates that the corresponding update mode
136 -- is available.
137 --
138 -- Prerequisites:
139 -- None.
140 --
141 -- In Parameters:
142 -- p_effective_date
143 -- Specifies the date at which the datetrack modes will be operated on.
144 -- p_base_key_value
145 -- Specifies the primary key value for this datetrack entity.
146 -- (E.g. For this entity the assignment of the argument would be:
147 -- p_base_key_value = :elig_obj_id).
148 --
149 -- Post Success:
150 -- Processing continues.
151 --
152 -- Post Failure:
153 -- Failure might occur if for the specified effective date and primary key
154 -- value a row doesn't exist.
155 --
156 -- Developer Implementation Notes:
157 -- This procedure could require changes if this entity has any sepcific
158 -- delete restrictions.
159 -- For example, this entity might disallow the datetrack update mode of
160 -- UPDATE. To implement this you would have to set and return a Boolean
161 -- value of FALSE after the call to the dt_api.find_dt_upd_modes procedure.
162 --
163 -- Access Status:
164 -- Internal Development Use Only.
165 --
166 -- {End Of Comments}
167 -- ----------------------------------------------------------------------------
168 Procedure find_dt_upd_modes
169 (p_effective_date in date
170 ,p_base_key_value in number
171 ,p_correction out nocopy boolean
172 ,p_update out nocopy boolean
173 ,p_update_override out nocopy boolean
174 ,p_update_change_insert out nocopy boolean
175 );
176 --
177 -- ----------------------------------------------------------------------------
178 -- |---------------------------< find_dt_del_modes >--------------------------|
179 -- ----------------------------------------------------------------------------
180 -- {Start Of Comments}
181 --
182 -- Description:
183 -- This procedure is used to determine what datetrack delete modes are
184 -- allowed as of the effective date for this entity. The procedure will
185 -- return a corresponding Boolean value for each of the delete modes
186 -- available where TRUE indicates that the corresponding delete mode is
187 -- available.
188 --
189 -- Prerequisites:
190 -- None.
191 --
192 -- In Parameters:
193 -- p_effective_date
194 -- Specifies the date at which the datetrack modes will be operated on.
195 -- p_base_key_value
196 -- Specifies the primary key value for this datetrack entity.
197 -- (E.g. For this entity the assignment of the argument would be:
198 -- p_base_key_value = :elig_obj_id).
199 --
200 -- Post Success:
201 -- Processing continues.
202 --
203 -- Post Failure:
204 -- Failure might occur if for the specified effective date and primary key
205 -- value a row doesn't exist.
206 --
207 -- Developer Implementation Notes:
208 -- This procedure could require changes if this entity has any sepcific
209 -- delete restrictions.
210 -- For example, this entity might disallow the datetrack delete mode of
211 -- ZAP. To implement this you would have to set and return a Boolean value
212 -- of FALSE after the call to the dt_api.find_dt_del_modes procedure.
213 --
214 -- Access Status:
215 -- Internal Development Use Only.
216 --
217 -- {End Of Comments}
218 -- ----------------------------------------------------------------------------
219 Procedure find_dt_del_modes
220 (p_effective_date in date
221 ,p_base_key_value in number
222 ,p_zap out nocopy boolean
223 ,p_delete out nocopy boolean
224 ,p_future_change out nocopy boolean
225 ,p_delete_next_change out nocopy boolean
226 );
227 --
228 -- ----------------------------------------------------------------------------
229 -- |-----------------------< upd_effective_end_date >-------------------------|
230 -- ----------------------------------------------------------------------------
231 -- {Start Of Comments}
232 --
233 -- Description:
234 -- This procedure will update the specified datetrack row with the
235 -- specified new effective end date. The object version number is also
236 -- set to the next object version number. DateTrack modes which call
237 -- this procedure are: UPDATE, UPDATE_CHANGE_INSERT,
238 -- UPDATE_OVERRIDE, DELETE, FUTURE_CHANGE and DELETE_NEXT_CHANGE.
239 -- This is an internal datetrack maintenance procedure which should
240 -- not be modified in anyway.
241 --
242 -- Prerequisites:
243 -- None.
244 --
245 -- In Parameters:
246 -- p_new_effective_end_date
247 -- Specifies the new effective end date which will be set for the
248 -- row as of the effective date.
249 -- p_base_key_value
250 -- Specifies the primary key value for this datetrack entity.
251 -- (E.g. For this entity the assignment of the argument would be:
252 -- p_base_key_value = :elig_obj_id).
253 --
254 -- Post Success:
255 -- The specified row will be updated with the new effective end date and
256 -- object_version_number.
257 --
258 -- Post Failure:
259 -- Failure might occur if for the specified effective date and primary key
260 -- value a row doesn't exist.
261 --
262 -- Developer Implementation Notes:
263 -- This is an internal datetrack maintenance procedure which should
264 -- not be modified in anyway.
265 --
266 -- Access Status:
267 -- Internal Row Handler Use Only.
268 --
269 -- {End Of Comments}
270 -- ----------------------------------------------------------------------------
271 Procedure upd_effective_end_date
272 (p_effective_date in date
273 ,p_base_key_value in number
274 ,p_new_effective_end_date in date
275 ,p_validation_start_date in date
276 ,p_validation_end_date in date
277 ,p_object_version_number out nocopy number
278 );
279 --
280 -- ----------------------------------------------------------------------------
281 -- |---------------------------------< lck >----------------------------------|
282 -- ----------------------------------------------------------------------------
283 -- {Start Of Comments}
284 --
285 -- Description:
286 -- The Lck process for datetrack is complicated and comprises of the
287 -- following processing
288 -- The processing steps are as follows:
289 -- 1) The row to be updated or deleted must be locked.
290 -- By locking this row, the g_old_rec record data type is populated.
291 -- 2) If a comment exists the text is selected from hr_comments.
292 -- 3) The datetrack mode is then validated to ensure the operation is
293 -- valid. If the mode is valid the validation start and end dates for
294 -- the mode will be derived and returned. Any required locking is
295 -- completed when the datetrack mode is validated.
296 --
297 -- Prerequisites:
298 -- When attempting to call the lck procedure the object version number,
299 -- primary key, effective date and datetrack mode must be specified.
300 --
301 -- In Parameters:
302 -- p_effective_date
303 -- Specifies the date of the datetrack update operation.
304 -- p_datetrack_mode
305 -- Determines the datetrack update or delete mode.
306 --
307 -- Post Success:
308 -- On successful completion of the Lck process the row to be updated or
309 -- deleted will be locked and selected into the global data structure
310 -- g_old_rec.
311 --
312 -- Post Failure:
313 -- The Lck process can fail for three reasons:
314 -- 1) When attempting to lock the row the row could already be locked by
315 -- another user. This will raise the HR_Api.Object_Locked exception.
316 -- 2) The row which is required to be locked doesn't exist in the HR Schema.
317 -- This error is trapped and reported using the message name
318 -- 'HR_7220_INVALID_PRIMARY_KEY'.
319 -- 3) The row although existing in the HR Schema has a different object
320 -- version number than the object version number specified.
321 -- This error is trapped and reported using the message name
322 -- 'HR_7155_OBJECT_INVALID'.
323 --
324 -- Developer Implementation Notes:
325 -- None.
326 --
327 -- Access Status:
328 -- Internal Development Use Only.
329 --
330 -- {End Of Comments}
331 -- ----------------------------------------------------------------------------
332 Procedure lck
333 (p_effective_date in date
334 ,p_datetrack_mode in varchar2
335 ,p_elig_obj_id in number
336 ,p_object_version_number in number
337 ,p_validation_start_date out nocopy date
338 ,p_validation_end_date out nocopy date
339 );
340 --
341 -- ----------------------------------------------------------------------------
342 -- |-----------------------------< convert_args >-----------------------------|
343 -- ----------------------------------------------------------------------------
344 -- {Start Of Comments}
345 --
346 -- Description:
347 -- This function is used to turn attribute parameters into the record
348 -- structure parameter g_rec_type.
349 --
350 -- Prerequisites:
351 -- This is a private function and can only be called from the ins or upd
352 -- attribute processes.
353 --
354 -- In Parameters:
355 --
356 -- Post Success:
357 -- A returning record structure will be returned.
358 --
359 -- Post Failure:
360 -- No direct error handling is required within this function. Any possible
361 -- errors within this function will be a PL/SQL value error due to
362 -- conversion of datatypes or data lengths.
363 --
364 -- Developer Implementation Notes:
365 -- None.
366 --
367 -- Access Status:
368 -- Internal Row Handler Use Only.
369 --
370 -- {End Of Comments}
371 -- ----------------------------------------------------------------------------
372 Function convert_args
373 (p_elig_obj_id in number
374 ,p_effective_start_date in date
375 ,p_effective_end_date in date
376 ,p_table_name in varchar2
377 ,p_column_name in varchar2
378 ,p_column_value in varchar2
379 ,p_business_group_id in number
380 ,p_object_version_number in number
381 )
382 Return g_rec_type;
383 --
384 end ben_beo_shd;
[Home] [Help]