1 Package pay_qpa_api AUTHID CURRENT_USER as
2 /* $Header: pyqpxrhi.pkh 115.6 2002/12/06 15:05:17 swinton noship $ */
3
4 --
5 -- ----------------------------------------------------------------------------
6 -- | Global Record Type Specification |
7 -- ----------------------------------------------------------------------------
8 --
9 Type g_rec_type Is Record
10 (payroll_action_id number(9)
11 ,business_group_id number(15)
12 ,consolidation_set_id number(9)
13 ,org_payment_method_id number(9)
14 ,action_status varchar2(9) -- Increased from length 1 to 9
15 ,effective_date date
16 ,comments long
17 ,current_task varchar2(30)
18 ,legislative_parameters varchar2(2000)
19 ,date_earned date
20 ,pay_advice_date date
21 ,pay_advice_message varchar2(240)
22 ,target_payroll_action_id number(9)
23 ,object_version_number number
24 ,report_type varchar2(30)
25 ,report_qualifier varchar2(30)
26 ,report_category varchar2(30)
27 ,run_type_id number(9)
28 );
29
30 --
31
32 --------------------------- qppsassact ------------------------------
33 /*
34 NAME
35 qpppassact - Insert a QuickPay Archival action.
36 DESCRIPTION
37 Process a QuickPay Archival assignment action.
38 NOTES
39 This procedure is meant to be called via the QuickPay form.
40 */
41 procedure qppsassact
42 (
43 p_payroll_action_id in number, -- of QuickPay Archival.
44 p_assignment_action_id out nocopy number,
45 p_object_version_number out nocopy number
46 );
47 --
48 -- |---------------------------------< lck >----------------------------------|
49 -- ----------------------------------------------------------------------------
50 -- {Start Of Comments}
51 --
52 -- Description:
53 -- The Lck process has two main functions to perform. Firstly, the row to be
54 -- updated or deleted must be locked. The locking of the row will only be
55 -- successful if the row is not currently locked by another user, the
56 -- specified object version numbers match and there is no AOL request
57 -- waiting or still running on the concurrent manager for this QuickPay
58 -- Archival. Secondly, during the locking of the row, the row is selected
59 -- into the g_old_rec data structure which enables the current row values
60 -- from the server to be available to the api.
61 --
62 -- Pre Conditions:
63 -- None.
64 --
65 -- In Arguments:
66 -- All the arguments to the Lck process are mandatory.
67 -- p_payroll_action_id is set to the id of the QuickPay Archival Payroll
68 -- Process.
69 -- p_p_object_version_number is set to the object_version_number for the
70 -- Payroll Process.
71 -- p_a_object_version_number is set to the object_version_number for the
72 -- Assignment Process.
73 --
74 -- Post Success:
75 -- The lock will only be successful if the payroll action is for a
76 -- QuickPay Archival.
77 -- On successful completion of the Lck process the row to be updated or
78 -- deleted will be locked and selected into the global data structure
79 -- g_old_rec.
80 --
81 -- Post Failure:
82 -- The Lck process can fail for four reasons:
83 -- 1) When attempting to lock the row the row could already be locked by
84 -- another user. This will raise the HR_7165_OBJECT_LOCKED error.
85 -- 2) The row which is required to be locked doesn't exist in the HR Schema.
86 -- This error is trapped and reported using the message name
87 -- 'HR_7155_OBJECT_INVALID'.
88 -- 3) The row although existing in the HR Schema has a different object
89 -- version number than the object version number specified.
90 -- This error is trapped and reported using the message name
91 -- 'HR_7155_OBJECT_INVALID'.
92 -- 4) An error is raised if an AOL concurrent request is waiting to run or
93 -- still running on the concurrent manager for this QuickPay Archival.
94 --
95 -- Access Status:
96 -- Public.
97 --
98 -- {End Of Comments}
99 --
100 procedure lck
101 (p_payroll_action_id in number
102 ,p_p_object_version_number in number
103 ,p_a_object_version_number in number
104 );
105 --
106 -- ----------------------------------------------------------------------------
107 -- |---------------------------------< upd >----------------------------------|
108 -- ----------------------------------------------------------------------------
109 -- {Start Of Comments}
110 --
111 -- Description:
112 -- This procedure is the record interface for the update business
113 -- process for the QuickPay Archival entity. The role of this process is
114 -- to update a fully validated row for the HR schema passing back
115 -- to the calling process, any system generated values (e.g.
116 -- object version number attribute). This process is the main
117 -- backbone of the upd business process. The processing of this
118 -- procedure is as follows:
119 -- 1) If the p_validate argument has been set to true then a savepoint
120 -- is issued.
121 -- 2) The row to be updated is then locked and selected into the record
122 -- structure g_old_rec.
123 -- 3) Because on update arguments which are not part of the update do not
124 -- have to be defaulted, we need to build up the updated row by
125 -- converting any system defaulted arguments to their corresponding
126 -- value.
127 -- 4) The controlling validation process update_validate is then executed
128 -- which will execute all private and public validation business rule
129 -- processes.
130 -- 5) The pre_update business process is then executed which enables any
131 -- logic to be processed before the update dml process is executed.
132 -- 6) The update_dml process will physical perform the update dml into the
133 -- specified entity.
134 -- 7) The post_update business process is then executed which enables any
135 -- logic to be processed after the update dml process.
136 -- 8) If the p_validate argument has been set to true an exception is
137 -- raised which is handled and processed by performing a rollback to
138 -- the savepoint which was issued at the beginning of the upd process.
139 --
140 -- Pre Conditions:
141 -- The main arguments to the business process have to be in the record
142 -- format.
143 --
144 -- In Arguments:
145 -- p_validate
146 -- Determines if the business process is to be validated. Setting this
147 -- boolean value to true will invoke the process to be validated. The
148 -- default is false. The validation is controlled by a savepoint and
149 -- rollback mechanism. The savepoint is issued at the beginning of the
150 -- business process and is rollbacked at the end of the business process
151 -- when all the processing has been completed. The rollback is controlled
152 -- by raising and handling the exception hr_api.validate_enabled. We use
153 -- the exception because, by raising the exception with the business
154 -- process, we can exit successfully without having any of the 'OUT'
155 -- arguments being set.
156 --
157 -- Post Success:
158 -- The specified row will be fully validated and updated for the specified
159 -- entity without being committed. If the p_validate argument has been set
160 -- to true then all the work will be rolled back.
161 --
162 -- Post Failure:
163 -- If an error has occurred, an error message will be supplied with the work
164 -- rolled back. A failure will occur if any of the business rules/conditions
165 -- are found:
166 -- 1) An AOL concurrent request is waiting to run or still running on the
167 -- concurrent manager for this QuickPay Archival.
168 -- 2) The QuickPay Archival Payroll Process current_task is not
169 -- null.
170 -- 3) If the action_status is being updated the only valid change is from
171 -- Complete to Mark for Retry. Any other attempted change to the
172 -- action_status will result in an error being raised.
173 --
174 -- Access Status:
175 -- Public.
176 --
177 -- {End Of Comments}
178 --
179 procedure upd
180 (p_rec in out nocopy g_rec_type
181 ,p_assignment_action_id in number
182 ,p_a_object_version_number in number
183 ,p_validate in boolean default false
184 );
185 --
186 -- ----------------------------------------------------------------------------
187 -- |---------------------------------< upd >----------------------------------|
188 -- ----------------------------------------------------------------------------
189 -- {Start Of Comments}
190 --
191 -- Description:
192 -- This procedure is the attribute interface for the update business
193 -- process for the QuickPay Archival entity and is the outermost layer.
194 -- The role of this process is to update a fully validated row into the HR
195 -- schema passing back to the calling process, any system generated values
196 -- (e.g. object version number attributes). The processing of this
197 -- procedure is as follows:
198 -- 1) The attributes are converted into a local record structure by
199 -- calling the convert_defs function.
200 -- 2) After the conversion has taken place, the corresponding record upd
201 -- interface business process is executed.
202 -- 3) OUT arguments are then set to their corresponding record arguments.
203 --
204 -- Pre Conditions:
205 --
206 -- In Arguments:
207 -- p_validate
208 -- Determines if the business process is to be validated. Setting this
209 -- Boolean value to true will invoke the process to be validated.
210 -- The default is false.
211 --
212 -- Post Success:
213 -- A fully validated row will be updated for the specified entity
214 -- without being committed (or rollbacked depending on the p_validate
215 -- status).
216 --
217 -- Post Failure:
218 -- If an error has occurred, an error message will be supplied with the work
219 -- rolled back.
220 --
221 -- Access Status:
222 -- Public.
223 --
224 -- {End Of Comments}
225 --
226 procedure upd
227 (p_payroll_action_id in number
228 ,p_assignment_action_id in number
229 ,p_action_status in varchar2 default hr_api.g_varchar2
230 ,p_p_object_version_number in out nocopy number
231 ,p_a_object_version_number in number
232 ,p_validate in boolean default false
233 );
234 --
235
236 -- ----------------------------------------------------------------------------
237 -- |------------------------< return_api_dml_status >-------------------------|
238 -- ----------------------------------------------------------------------------
239
240 -- {Start Of Comments}
241 --
242 -- Description:
243 -- This function will return the current g_api_dml private global
244 -- boolean status.
245 -- The g_api_dml status determines if at the time of the function
246 -- being executed if a dml statement (i.e. INSERT, UPDATE or DELETE)
247 -- is being issued from within an api.
248 -- If the status is TRUE then a dml statement is being issued from
249 -- within this entity api.
250 -- This function is primarily to support database triggers which
251 -- need to maintain the object_version_number for non-supported
252 -- dml statements (i.e. dml statement issued outside of the api layer).
253 --
254 -- Pre Conditions:
255 -- None.
256 --
257 -- In Arguments:
258 -- None.
259 --
260 -- Post Success:
261 -- Processing continues.
262 -- If the function returns a TRUE value then, dml is being executed from
263 -- within this api.
264 --
265 -- Post Failure:
266 -- None.
267 --
268 -- Access Status:
269 -- Public.
270 --
271 -- {End Of Comments}
272 --
273 Function return_api_dml_status Return Boolean;
274 --
275 -- ----------------------------------------------------------------------------
276 -- |---------------------------------< ins >----------------------------------|
277 -- ----------------------------------------------------------------------------
278 -- {Start Of Comments}
279 --
280 -- Description:
281 -- This procedure is the record interface for the insert business process
282 -- for the Archival process. The role of this process is to
283 -- insert a fully validated row, into the HR schema passing back to the
284 -- calling process, any system generated values (e.g. primary and object
285 -- version number attributes). This process is the main backbone of the ins
286 -- business process. The processing of this procedure is as follows:
287 -- 1) If the p_validate argument has been set to true then a savepoint is
288 -- issued.
289 -- 2) The controlling validation process insert_validate is then executed
290 -- which will execute all private and public validation business rule
291 -- processes.
292 -- 3) The pre_insert business process is then executed which enables any
293 -- logic to be processed before the insert dml process is executed.
294 -- 4) The insert_dml process will physical perform the insert dml into the
295 -- specified entity.
296 -- 5) The post_insert business process is then executed which enables any
297 -- logic to be processed after the insert dml process.
298 -- 6) If the p_validate argument has been set to true an exception is raised
299 -- which is handled and processed by performing a rollback to the
300 -- savepoint which was issued at the beginning of the Ins process.
301 --
302 -- Pre Conditions:
303 -- The main arguments to the business process have to be in the record
304 -- format.
305 --
306 -- In Arguments:
307 -- p_validate
308 -- Determines if the business process is to be validated. Setting this
309 -- boolean value to true will invoke the process to be validated. The
310 -- default is false. The validation is controlled by a savepoint and
311 -- rollback mechanism. The savepoint is issued at the beginning of the
312 -- business process and is rollbacked at the end of the business process
313 -- when all the processing has been completed. The rollback is controlled
314 -- by raising and handling the exception hr_api.validate_enabled. We use
315 -- the exception because, by raising the exception with the business
316 -- process, we can exit successfully without having any of the 'OUT'
317 -- arguments being set.
318 --
319 -- Post Success:
320 -- A fully validated row will be inserted into the specified entity
321 -- without being committed. If the p_validate argument has been set to true
322 -- then all the work will be rolled back.
323 --
324
325 -- Post Failure:
326 -- If an error has occurred, an error message will be supplied with the work
327 -- rolled back. A failure will occur if any of the business rules/conditions
328 -- are found:
329 -- 1) p_rec.target_payroll_action_id, p_rec.business_group_id or
330 -- p_rec.effective_date are not null.
331 -- 2) p_rec.target_payroll_action_id does not exists in pay_payroll_actions
332 -- for a QuickPay Run Payroll Process.
333 -- 3) The associated Assignment Process has a complete status.
334 -- 4) Another QuickPay Archival process already
335 -- interlocks the QuickPay Run Assignment Process.
336 -- 5) The QuickPay Archival business_group_id and date_paid
337 -- (effective_date) are not the same as the QuickPay Run
338 -- business_group_id and date_paid.
339 -- 6) If p_rec.org_payment_method_id is not null and it does not exist in
340 -- pay_org_payment_methods_f of the QuickPay Run date paid.
341 -- 7) If p_rec.org_payment_method_id is not null and does not exist in the
342 -- same business group as the QuickPay Archival.
343 -- 8) If p_rec.org_payment_method_id is not null the corresponding payment
344 -- category must not be magnetic transfer.
345 --
346 -- {End Of Comments}
347 --
348 Procedure ins
349 (p_rec in out nocopy g_rec_type
350 ,p_assignment_action_id out nocopy number
351 ,p_a_object_version_number out nocopy number
352 ,p_validate in boolean default false
353 );
354 --
355 -- ----------------------------------------------------------------------------
356 -- |---------------------------------< ins >----------------------------------|
357 -- ----------------------------------------------------------------------------
358 -- {Start Of Comments}
359 --
360 -- Description:
361 -- This procedure is the attribute interface for the insert business
362 -- process for the QuickPay Archival and is the outermost layer.
363 -- The role of this process is to insert a fully validated row into the HR
364 -- schema passing back to the calling process, any system generated values
365 -- (e.g. the primary key and the object version numbers).The processing of
366 -- this procedure is as follows:
367 -- 1) The attributes are converted into a local record structure by
368 -- calling the convert_defs function.
369 -- 2) After the conversion has taken place, the corresponding record ins
370 -- interface business process is executed.
371 -- 3) OUT arguments are then set to their corresponding record arguments.
372 --
373 -- Pre Conditions:
374 --
375 -- In Arguments:
376 -- p_validate
377 -- Determines if the business process is to be validated. Setting this
378 -- Boolean value to true will invoke the process to be validated.
379 -- The default is false.
380 --
381 -- Post Success:
382 -- A fully validated row will be inserted for the specified entity
383 -- without being committed (or rollbacked depending on the p_validate
384 -- status)
385 --
386 -- Post Failure:
387 -- If an error has occurred, an error message will be supplied with the work
388 -- rolled back
389 --
390 -- Access Status:
391 -- Public.
392 --
393 -- {End Of Comments}
394 --
395 Procedure ins
396 (p_business_group_id in number
397 ,p_org_payment_method_id in number default null
398 ,p_effective_date in date
399 ,p_target_payroll_action_id in number default null
400 ,p_legislative_parameters in varchar2
401 ,p_report_type in varchar2
402 ,p_report_qualifier in varchar2
403 ,p_report_category in varchar2
404 ,p_payroll_action_id out nocopy number
405 ,p_action_status out nocopy varchar2
406 ,p_p_object_version_number out nocopy number
407 ,p_assignment_action_id out nocopy number
408 ,p_a_object_version_number out nocopy number
409 ,p_validate in boolean default false
410 );
411 --
412
413 --
414
415 end pay_qpa_api;
[Home] [Help]