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