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