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