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