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