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