1 Package OTA_VSP_API AUTHID CURRENT_USER as
2 /* $Header: otvsp01t.pkh 115.2 2002/11/29 13:23:50 jbharath ship $ */
3 --
7 --
4 -- ----------------------------------------------------------------------------
5 -- | Global Record Type Specification |
6 -- ----------------------------------------------------------------------------
8 Type g_rec_type Is Record
9 (
10 vendor_supply_id number(9),
11 vendor_id number(15),
12 activity_version_id number(9),
13 primary_supplier_flag varchar2(30),
14 comments varchar2(2000)
15 );
16 --
17 -- ----------------------------------------------------------------------------
18 -- -------------------------< CHECK_UNIQUE_TAV_VEN >---------------------------
19 -- ----------------------------------------------------------------------------
20 --
21 -- The combination of Activity Version ID and Vendor ID must be unique.
22 --
23 procedure CHECK_UNIQUE_TAV_VEN
24 (
25 P_ACTIVITY_VERSION_ID in number,
26 P_VENDOR_ID in number
27 );
28 --
29 -- ----------------------------------------------------------------------------
30 -- -------------------------< CHECK_SINGLE_PRIMARY >---------------------------
31 -- ----------------------------------------------------------------------------
32 --
33 -- There may only be a single Primary vendor for each Activity Version
34 --
35 procedure CHECK_SINGLE_PRIMARY
36 (
37 P_ACTIVITY_VERSION_ID in number,
38 P_VENDOR_ID in number,
39 P_PRIMARY_SUPPLIER_FLAG in varchar
40 );
41 --
42 -- ----------------------------------------------------------------------------
43 -- |-------------------------< copy_vendor_supply >---------------------------|
44 -- ----------------------------------------------------------------------------
45 --
46 -- PUBLIC
47 -- Description:
48 -- Copies all vendor supply information from a given activity version to
49 -- another activity version.
50 --
51 Procedure copy_vendor_supply
52 (
53 p_activity_version_from in number
54 ,p_activity_version_to in number
55 );
56 --
57 -- ----------------------------------------------------------------------------
58 -- |------------------------< return_api_dml_status >-------------------------|
59 -- ----------------------------------------------------------------------------
60 -- {Start Of Comments}
61 --
62 -- Description:
63 -- This function will return the current g_api_dml private global
64 -- boolean status.
65 -- The g_api_dml status determines if at the time of the function
66 -- being executed if a dml statement (i.e. INSERT, UPDATE or DELETE)
67 -- is being issued from within an api.
68 -- If the status is TRUE then a dml statement is being issued from
69 -- within this entity api.
70 -- This function is primarily to support database triggers which
71 -- need to maintain the object_version_number for non-supported
72 -- dml statements (i.e. dml statement issued outside of the api layer).
73 --
74 -- Pre Conditions:
75 -- None.
76 --
77 -- In Arguments:
78 -- None.
79 --
80 -- Post Success:
81 -- Processing continues.
82 -- If the function returns a TRUE value then, dml is being executed from
83 -- within this api.
84 --
85 -- Post Failure:
86 -- None.
87 --
88 -- {End Of Comments}
89 -- ----------------------------------------------------------------------------
90 Function return_api_dml_status Return Boolean;
91 --
92 -- ----------------------------------------------------------------------------
93 -- |---------------------------------< lck >----------------------------------|
94 -- ----------------------------------------------------------------------------
95 -- {Start Of Comments}
96 --
97 -- Description:
98 -- The Lck process has two main functions to perform. Firstly, the row to be
99 -- updated or deleted must be locked. The locking of the row will only be
100 -- successful if the row is not currently locked by another user and the
101 -- specified object version number match. Secondly, during the locking of
102 -- the row, the row is selected into the g_old_rec data structure which
103 -- enables the current row values from the server to be available to the api.
104 --
105 -- Pre Conditions:
106 -- When attempting to call the lock the object version number (if defined)
107 -- is mandatory.
108 --
109 -- In Arguments:
110 -- The arguments to the Lck process are the primary key(s) which uniquely
111 -- identify the row and the object version number of row.
112 --
113 -- Post Success:
114 -- On successful completion of the Lck process the row to be updated or
115 -- deleted will be locked and selected into the global data structure
116 -- g_old_rec.
117 --
118 -- Post Failure:
119 -- The Lck process can fail for three reasons:
120 -- 1) When attempting to lock the row the row could already be locked by
121 -- another user. This will raise the HR_Api.Object_Locked exception.
122 -- 2) The row which is required to be locked doesn't exist in the HR Schema.
123 -- This error is trapped and reported using the message name
124 -- 'HR_7155_OBJECT_INVALID'.
125 -- 3) The row although existing in the HR Schema has a different object
126 -- version number than the object version number specified.
127 -- This error is trapped and reported using the message name
128 -- 'HR_7155_OBJECT_INVALID'.
129 --
130 -- Developer Implementation Notes:
131 -- For each primary key and the object version number arguments add a
135 -- {End Of Comments}
132 -- call to hr_api.mandatory_arg_error procedure to ensure that these
133 -- argument values are not null.
134 --
136 -- ----------------------------------------------------------------------------
137 Procedure lck
138 (
139 p_vendor_supply_id in number
140 );
141 --
142 -- ----------------------------------------------------------------------------
143 -- |---------------------------------< ins >----------------------------------|
144 -- ----------------------------------------------------------------------------
145 -- {Start Of Comments}
146 --
147 -- Description:
148 -- This procedure is the record interface for the insert business process
149 -- for the specified entity. The role of this process is to insert a fully
150 -- validated row, into the HR schema passing back to the calling process,
151 -- any system generated values (e.g. primary and object version number
152 -- attributes). This process is the main backbone of the ins business
153 -- process. The processing of this procedure is as follows:
154 -- 1) If the p_validate argument has been set to true then a savepoint is
155 -- issued.
156 -- 2) The controlling validation process insert_validate is then executed
157 -- which will execute all private and public validation business rule
158 -- processes.
159 -- 3) The pre_insert business process is then executed which enables any
160 -- logic to be processed before the insert dml process is executed.
161 -- 4) The insert_dml process will physical perform the insert dml into the
162 -- specified entity.
163 -- 5) The post_insert business process is then executed which enables any
164 -- logic to be processed after the insert dml process.
165 -- 6) If the p_validate argument has been set to true an exception is raised
166 -- which is handled and processed by performing a rollback to the
167 -- savepoint which was issued at the beginning of the Ins process.
168 --
169 -- Pre Conditions:
170 -- The main arguments to the business process have to be in the record
171 -- format.
172 --
173 -- In Arguments:
174 -- p_validate
175 -- Determines if the business process is to be validated. Setting this
176 -- boolean value to true will invoke the process to be validated. The
177 -- default is false. The validation is controlled by a savepoint and
178 -- rollback mechanism. The savepoint is issued at the beginning of the
179 -- business process and is rollbacked at the end of the business process
180 -- when all the processing has been completed. The rollback is controlled
181 -- by raising and handling the exception hr_api.validate_enabled. We use
182 -- the exception because, by raising the exception with the business
183 -- process, we can exit successfully without having any of the 'OUT'
184 -- arguments being set.
185 --
186 -- Post Success:
187 -- A fully validated row will be inserted into the specified entity
188 -- without being committed. If the p_validate argument has been set to true
189 -- then all the work will be rolled back.
190 --
191 -- Post Failure:
192 -- If an error has occurred, an error message will be supplied with the work
193 -- rolled back.
194 --
195 -- Developer Implementation Notes:
196 --
197 -- {End Of Comments}
198 -- ----------------------------------------------------------------------------
199 Procedure ins
200 (
201 p_rec in out nocopy g_rec_type,
202 p_validate in boolean default false
203 );
204 --
205 -- ----------------------------------------------------------------------------
206 -- |---------------------------------< ins >----------------------------------|
207 -- ----------------------------------------------------------------------------
208 -- {Start Of Comments}
209 --
210 -- Description:
211 -- This procedure is the attribute interface for the insert business
212 -- process for the specified entity and is the outermost layer. The role
213 -- of this process is to insert a fully validated row into the HR schema
214 -- passing back to the calling process, any system generated values
215 -- (e.g. object version number attributes).The processing of this
216 -- procedure is as follows:
217 -- 1) The attributes are converted into a local record structure by
218 -- calling the convert_defs function.
219 -- 2) After the conversion has taken place, the corresponding record ins
220 -- interface business process is executed.
221 -- 3) OUT arguments are then set to their corresponding record arguments.
222 --
223 -- Pre Conditions:
224 --
225 -- In Arguments:
226 -- p_validate
227 -- Determines if the business process is to be validated. Setting this
228 -- Boolean value to true will invoke the process to be validated.
229 -- The default is false.
230 --
231 -- Post Success:
232 -- A fully validated row will be inserted for the specified entity
233 -- without being committed (or rollbacked depending on the p_validate
234 -- status).
235 --
236 -- Post Failure:
237 -- If an error has occurred, an error message will be supplied with the work
238 -- rolled back.
239 --
240 -- Developer Implementation Notes:
241 --
242 -- {End Of Comments}
243 -- ----------------------------------------------------------------------------
244 Procedure ins
245 (
246 p_vendor_supply_id out nocopy number,
247 p_vendor_id in number,
248 p_activity_version_id in number,
249 p_primary_supplier_flag in varchar2,
250 p_comments in varchar2 default null,
251 p_validate in boolean default false
252 );
253 --
257 -- {Start Of Comments}
254 -- ----------------------------------------------------------------------------
255 -- |---------------------------------< upd >----------------------------------|
256 -- ----------------------------------------------------------------------------
258 --
259 -- Description:
260 -- This procedure is the record interface for the update business
261 -- process for the specified entity. The role of this process is
262 -- to update a fully validated row for the HR schema passing back
263 -- to the calling process, any system generated values (e.g.
264 -- object version number attribute). This process is the main
265 -- backbone of the upd business process. The processing of this
266 -- procedure is as follows:
267 -- 1) If the p_validate argument has been set to true then a savepoint
268 -- is issued.
269 -- 2) The row to be updated is then locked and selected into the record
270 -- structure g_old_rec.
271 -- 3) Because on update arguments which are not part of the update do not
272 -- have to be defaulted, we need to build up the updated row by
273 -- converting any system defaulted arguments to their corresponding
274 -- value.
275 -- 4) The controlling validation process update_validate is then executed
276 -- which will execute all private and public validation business rule
277 -- processes.
278 -- 5) The pre_update business process is then executed which enables any
279 -- logic to be processed before the update dml process is executed.
280 -- 6) The update_dml process will physical perform the update dml into the
281 -- specified entity.
282 -- 7) The post_update business process is then executed which enables any
283 -- logic to be processed after the update dml process.
284 -- 8) If the p_validate argument has been set to true an exception is
285 -- raised which is handled and processed by performing a rollback to
286 -- the savepoint which was issued at the beginning of the upd process.
287 --
288 -- Pre Conditions:
289 -- The main arguments to the business process have to be in the record
290 -- format.
291 --
292 -- In Arguments:
293 -- p_validate
294 -- Determines if the business process is to be validated. Setting this
295 -- boolean value to true will invoke the process to be validated. The
296 -- default is false. The validation is controlled by a savepoint and
297 -- rollback mechanism. The savepoint is issued at the beginning of the
298 -- business process and is rollbacked at the end of the business process
299 -- when all the processing has been completed. The rollback is controlled
300 -- by raising and handling the exception hr_api.validate_enabled. We use
301 -- the exception because, by raising the exception with the business
302 -- process, we can exit successfully without having any of the 'OUT'
303 -- arguments being set.
304 --
305 -- Post Success:
306 -- The specified row will be fully validated and updated for the specified
307 -- entity without being committed. If the p_validate argument has been set
308 -- to true then all the work will be rolled back.
309 --
310 -- Post Failure:
311 -- If an error has occurred, an error message will be supplied with the work
312 -- rolled back.
313 --
314 -- Developer Implementation Notes:
315 --
316 -- {End Of Comments}
317 -- ----------------------------------------------------------------------------
318 Procedure upd
319 (
320 p_rec in out nocopy g_rec_type,
321 p_validate in boolean default false
322 );
323 --
324 -- ----------------------------------------------------------------------------
325 -- |---------------------------------< upd >----------------------------------|
326 -- ----------------------------------------------------------------------------
327 -- {Start Of Comments}
328 --
329 -- Description:
330 -- This procedure is the attribute interface for the update business
331 -- process for the specified entity and is the outermost layer. The role
332 -- of this process is to update a fully validated row into the HR schema
333 -- passing back to the calling process, any system generated values
334 -- (e.g. object version number attributes).The processing of this
335 -- procedure is as follows:
336 -- 1) The attributes are converted into a local record structure by
337 -- calling the convert_defs function.
338 -- 2) After the conversion has taken place, the corresponding record upd
339 -- interface business process is executed.
340 -- 3) OUT arguments are then set to their corresponding record arguments.
341 --
342 -- Pre Conditions:
343 --
344 -- In Arguments:
345 -- p_validate
346 -- Determines if the business process is to be validated. Setting this
347 -- Boolean value to true will invoke the process to be validated.
348 -- The default is false.
349 --
350 -- Post Success:
351 -- A fully validated row will be updated for the specified entity
352 -- without being committed (or rollbacked depending on the p_validate
353 -- status).
354 --
355 -- Post Failure:
356 -- If an error has occurred, an error message will be supplied with the work
357 -- rolled back.
358 --
359 -- Developer Implementation Notes:
360 --
361 -- {End Of Comments}
362 -- ----------------------------------------------------------------------------
363 Procedure upd
364 (
365 p_vendor_supply_id in number,
366 p_vendor_id in number default hr_api.g_number,
367 p_activity_version_id in number default hr_api.g_number,
368 p_primary_supplier_flag in varchar2 default hr_api.g_varchar2,
369 p_comments in varchar2 default hr_api.g_varchar2,
373 -- ----------------------------------------------------------------------------
370 p_validate in boolean default false
371 );
372 --
374 -- |---------------------------------< del >----------------------------------|
375 -- ----------------------------------------------------------------------------
376 -- {Start Of Comments}
377 --
378 -- Description:
379 -- This procedure is the record interface for the delete business process
380 -- for the specified entity. The role of this process is to delete the
381 -- row from the HR schema. This process is the main backbone of the del
382 -- business process. The processing of this procedure is as follows:
383 -- 1) If the p_validate argument has been set to true then a savepoint is
384 -- issued.
385 -- 2) The controlling validation process delete_validate is then executed
386 -- which will execute all private and public validation business rule
387 -- processes.
388 -- 3) The pre_delete business process is then executed which enables any
389 -- logic to be processed before the delete dml process is executed.
390 -- 4) The delete_dml process will physical perform the delete dml for the
391 -- specified row.
392 -- 5) The post_delete business process is then executed which enables any
393 -- logic to be processed after the delete dml process.
394 -- 6) If the p_validate argument has been set to true an exception is raised
395 -- which is handled and processed by performing a rollback to the
396 -- savepoint which was issued at the beginning of the del process.
397 --
398 -- Pre Conditions:
399 -- The main arguments to the business process have to be in the record
400 -- format.
401 --
402 -- In Arguments:
403 -- p_validate
404 -- Determines if the business process is to be validated. Setting this
405 -- boolean value to true will invoke the process to be validated. The
406 -- default is false. The validation is controlled by a savepoint and
407 -- rollback mechanism. The savepoint is issued at the beginning of the
408 -- business process and is rollbacked at the end of the business process
409 -- when all the processing has been completed. The rollback is controlled
410 -- by raising and handling the exception hr_api.validate_enabled. We use
411 -- the exception because, by raising the exception with the business
412 -- process, we can exit successfully without having any of the 'OUT'
413 -- arguments being set.
414 --
415 -- Post Success:
416 -- The specified row will be fully validated and deleted for the specified
417 -- entity without being committed. If the p_validate argument has been set
418 -- to true then all the work will be rolled back.
419 --
420 -- Post Failure:
421 -- If an error has occurred, an error message will be supplied with the work
422 -- rolled back.
423 --
424 -- Developer Implementation Notes:
425 --
426 -- {End Of Comments}
427 -- ----------------------------------------------------------------------------
428 Procedure del
429 (
430 p_rec in g_rec_type,
431 p_validate in boolean default false
432 );
433 --
434 -- ----------------------------------------------------------------------------
435 -- |---------------------------------< del >----------------------------------|
436 -- ----------------------------------------------------------------------------
437 -- {Start Of Comments}
438 --
439 -- Description:
440 -- This procedure is the attribute interface for the delete business
441 -- process for the specified entity and is the outermost layer. The role
442 -- of this process is to validate and delete the specified row from the
443 -- HR schema. The processing of this procedure is as follows:
444 -- 1) The attributes are converted into a local record structure by
445 -- explicitly coding the attribute arguments into the g_rec_type
446 -- datatype.
447 -- 2) After the conversion has taken place, the corresponding record del
448 -- interface business process is executed.
449 --
450 -- Pre Conditions:
451 --
452 -- In Arguments:
453 -- p_validate
454 -- Determines if the business process is to be validated. Setting this
455 -- Boolean value to true will invoke the process to be validated.
456 -- The default is false.
457 --
458 -- Post Success:
459 -- The specified row will be fully validated and deleted for the specified
460 -- entity without being committed (or rollbacked depending on the
461 -- p_validate status).
462 --
463 -- Post Failure:
464 -- If an error has occurred, an error message will be supplied with the work
465 -- rolled back.
466 --
467 -- Developer Implementation Notes:
468 -- The attrbute in arguments should be modified as to the business process
469 -- requirements.
470 --
471 -- {End Of Comments}
472 -- ----------------------------------------------------------------------------
473 Procedure del
474 (
475 p_vendor_supply_id in number,
476 p_validate in boolean default false
477 );
478 --
479 end OTA_VSP_API;
[Home] [Help]