1 Package pay_qpe_api AUTHID CURRENT_USER as
2 /* $Header: pyqperhi.pkh 115.1 2004/01/13 01:09 swinton noship $ */
3 --
4 -- ----------------------------------------------------------------------------
5 -- |---------------------------------< lck >----------------------------------|
6 -- ----------------------------------------------------------------------------
7 -- {Start Of Comments}
8 --
9 -- Description:
10 -- The Lck process has two main functions to perform. Firstly, the row to be
11 -- deleted must be locked. The locking of the row will only be
12 -- successful if the row is not currently locked by another user.
13 -- Secondly, during the locking of the row, the row is selected into
14 -- the g_old_rec data structure which enables the current row values from the
15 -- server to be available to the api.
16 --
17 -- Pre Conditions:
18 -- None.
19 --
20 -- In Arguments:
21 -- The arguments to the Lck process are the primary key(s) which uniquely
22 -- identify the row (element_entry_id and assignment_action_id).
23 --
24 -- Post Success:
25 -- On successful completion of the Lck process the row to be updated or
26 -- deleted will be locked and selected into the global data structure
27 -- g_old_rec.
28 --
29 -- Post Failure:
30 -- The Lck process can fail for two reasons:
31 -- 1) When attempting to lock the row the row could already be locked by
32 -- another user. This will raise the error HR_7165_OBJECT_LOCKED.
33 -- 2) The row which is required to be locked doesn't exist in the HR Schema.
34 -- This error is trapped and reported using the message name
35 -- 'HR_7220_INVALID_PRIMARY_KEY'.
36 --
37 -- Access Status:
38 -- Public.
39 --
40 -- {End Of Comments}
41 --
42 PROCEDURE lck
43 (p_element_entry_id IN NUMBER
44 ,p_assignment_action_id IN NUMBER
45 );
46 --
47 -- ----------------------------------------------------------------------------
48 -- |---------------------------------< ins >----------------------------------|
49 -- ----------------------------------------------------------------------------
50 -- {Start Of Comments}
51 --
52 -- Description:
53 -- This procedure is the record interface for the insert business process
54 -- for the PAY_QUICKPAY_EXCLUSIONS entity. The role of this process is to
55 -- insert a fully validated row, into the HR schema.
56 -- 1) If the p_validate argument has been set to true then a savepoint is
57 -- issued.
58 -- 2) The controlling validation process insert_validate is then executed
59 -- which will execute all private and public validation business rule
60 -- processes.
61 -- 3) The insert_dml process will physical perform the insert dml into the
62 -- specified entity.
63 -- 4) If the p_validate argument has been set to true an exception is raised
64 -- which is handled and processed by performing a rollback to the
65 -- savepoint which was issued at the beginning of the Ins process.
66 --
67 -- Pre Conditions:
68 -- The main arguments to the business process have to be in the record
69 -- format.
70 --
71 -- In Arguments:
72 -- p_validate
73 -- Determines if the business process is to be validated. Setting this
74 -- boolean value to true will invoke the process to be validated. The
75 -- default is false. The validation is controlled by a savepoint and
76 -- rollback mechanism. The savepoint is issued at the beginning of the
77 -- business process and is rollbacked at the end of the business process
78 -- when all the processing has been completed. The rollback is controlled
79 -- by raising and handling the exception hr_api.validate_enabled. We use
80 -- the exception because, by raising the exception with the business
81 -- process, we can exit successfully without having any of the 'OUT'
82 -- arguments being set.
83 --
84 -- Post Success:
85 -- A fully validated row will be inserted into the specified entity
86 -- without being committed. If the p_validate argument has been set to true
87 -- then all the work will be rolled back.
88 --
89 -- Post Failure:
90 -- If an error has occurred, an error message will be supplied with the work
91 -- rolled back.
92 -- An insert will be disallowed if any of the following conditions are
93 -- found:
94 -- 1) An Assignment Process with an id of p_rec.assignment_action_id does
95 -- not exist.
96 -- 2) The Assignment Process does exist but it is not for a 'QuickPay Run'
97 -- Payroll Process.
98 -- 3) The Assignment Process has a status of complete and a run result
99 -- exists for the element entry/assignment action id being excluded.
100 -- 4) The Payroll Process current_task is not null.
101 -- 5) No Element Entry exists with an id of p_rec.element_entry_id.
102 -- 6) The entry is not for the assignment defined on the QuickPay Run
103 -- definition.
104 -- 7) The element entry does not exist as of the QuickPay date earned.
105 -- 8) A QuickPay Exclusion for this Assignment Process and Element Entry
106 -- already exists.
107 --
108 -- Access Status:
109 -- Public.
110 --
111 -- {End Of Comments}
112 --
113 PROCEDURE ins
114 (p_rec IN OUT NOCOPY pay_quickpay_exclusions%ROWTYPE
115 ,p_validate IN BOOLEAN DEFAULT FALSE
116 );
117 --
118 -- ----------------------------------------------------------------------------
119 -- |---------------------------------< ins >----------------------------------|
120 -- ----------------------------------------------------------------------------
121 -- {Start Of Comments}
122 --
123 -- Description:
124 -- This procedure is the attribute interface for the insert business
125 -- process for QuickPay Exclusions and is the outermost layer. The role
126 -- of this process is to insert a fully validated row into the HR schema.
127 -- The processing of this procedure is as follows:
128 -- 1) The attributes are converted into a local record structure by
129 -- calling an internal convert_args function.
130 -- 2) After the conversion has taken place, the corresponding record ins
131 -- interface business process is executed.
132 -- 3) OUT arguments are then set to their corresponding record arguments.
133 --
134 -- Pre Conditions:
135 --
136 -- In Arguments:
137 -- p_validate
138 -- Determines if the business process is to be validated. Setting this
139 -- Boolean value to true will invoke the process to be validated.
140 -- The default is false.
141 --
142 -- Post Success:
143 -- A fully validated row will be inserted for QuickPay Exclusions
144 -- without being committed (or rolled back, depending on the p_validate
145 -- status).
146 --
147 -- Post Failure:
148 -- If an error has occurred, an error message will be supplied with the work
149 -- rolled back. For full details of the error conditions refer to the
150 -- 'ins' record interface.
151 --
152 -- Developer Implementation Notes:
153 -- None.
154 --
155 -- Access Status:
156 -- Public.
157 --
158 -- {End Of Comments}
159 --
160 PROCEDURE ins
161 (p_element_entry_id IN NUMBER
162 ,p_assignment_action_id IN NUMBER
163 ,p_validate IN BOOLEAN DEFAULT FALSE
164 );
165 --
166 -- ----------------------------------------------------------------------------
167 -- |---------------------------------< del >----------------------------------|
168 -- ----------------------------------------------------------------------------
169 -- {Start Of Comments}
170 --
171 -- Description:
172 -- This procedure is the record interface for the delete business process
173 -- for QuickPay Exclusions. The role of this process is to delete the
174 -- row from the HR schema. This process is the main backbone of the del
175 -- business process. The processing of this procedure is as follows:
176 -- 1) If the p_validate argument has been set to true then a savepoint is
177 -- issued.
178 -- 2) The controlling validation process delete_validate is then executed
179 -- which will execute all private and public validation business rule
180 -- processes.
181 -- 3) The pre_delete business process is then executed which enables any
182 -- logic to be processed before the delete dml process is executed.
183 -- 4) The delete_dml process will physical perform the delete dml for the
184 -- specified row.
185 -- 5) The post_delete business process is then executed which enables any
186 -- logic to be processed after the delete dml process.
187 -- 6) If the p_validate argument has been set to true an exception is raised
188 -- which is handled and processed by performing a rollback to the
189 -- savepoint which was issued at the beginning of the del process.
190 --
191 -- Pre Conditions:
192 -- The main arguments to the business process have to be in the record
193 -- format.
194 --
195 -- In Arguments:
196 -- p_validate
197 -- Determines if the business process is to be validated. Setting this
198 -- boolean value to true will invoke the process to be validated. The
199 -- default is false. The validation is controlled by a savepoint and
200 -- rollback mechanism. The savepoint is issued at the beginning of the
201 -- business process and is rollbacked at the end of the business process
202 -- when all the processing has been completed. The rollback is controlled
203 -- by raising and handling the exception hr_api.validate_enabled. We use
204 -- the exception because, by raising the exception with the business
205 -- process, we can exit successfully without having any of the 'OUT'
206 -- arguments being set.
207 --
208 -- Post Success:
209 -- The specified row will be fully validated and deleted without being
210 -- committed. If the p_validate argument has been set to true then all the
211 -- work will be rolled back.
212 --
213 -- Post Failure:
214 -- If an error has occurred, an error message will be supplied with the work
215 -- rolled back.
216 -- A delete will be disallowed if any of the following conditions are
217 -- found:
218 -- 1) The corresponding Payroll Process has a current_task which is
219 -- not null.
220 --
221 -- Developer Implementation Notes:
222 -- None.
223 --
224 -- Access Status:
225 -- Public.
226 --
227 -- {End Of Comments}
228 --
229 PROCEDURE del
230 (p_rec IN pay_quickpay_exclusions%ROWTYPE
231 ,p_validate IN BOOLEAN DEFAULT FALSE
232 );
233 --
234 -- ----------------------------------------------------------------------------
235 -- |---------------------------------< del >----------------------------------|
236 -- ----------------------------------------------------------------------------
237 -- {Start Of Comments}
238 --
239 -- Description:
240 -- This procedure is the attribute interface for the delete business
241 -- process for QuickPay Exclusions and is the outermost layer. The role
242 -- of this process is to validate and delete the specified row from the
243 -- HR schema. The processing of this procedure is as follows:
244 -- 1) The attributes are converted into a local record structure by
245 -- explicitly coding the attribute arguments into the
246 -- pay_quickpay_exclusions%ROWTYPE datatype.
247 -- 2) After the conversion has taken place, the corresponding record del
248 -- interface business process is executed.
249 --
250 -- Pre Conditions:
251 --
252 -- In Arguments:
253 -- p_validate
254 -- Determines if the business process is to be validated. Setting this
255 -- Boolean value to true will invoke the process to be validated.
256 -- The default is false.
257 --
258 -- Post Success:
259 -- The specified row will be fully validated and deleted for the specified
260 -- entity without being committed (or rolled back depending on the
261 -- p_validate status).
262 --
263 -- Post Failure:
264 -- If an error has occurred, an error message will be supplied with the work
265 -- rolled back.
266 --
267 -- Access Status:
268 -- Public.
269 --
270 -- {End Of Comments}
271 --
272 procedure del
273 (p_element_entry_id in number
274 ,p_assignment_action_id in number
275 ,p_validate in boolean default false
276 );
277 end pay_qpe_api;
[Home] [Help]