eTRM uses javascript that opens and focuses a separate window to display reports. Your browser does not appear to support javascript. This should not prevent you from using eTRM but it does mean the window focus feature will not work. Please check the contents of other windows on your desktop if you click on a link that does not appear to do anything.

APPS.QA_BIS dependencies on QA_RESULTS

Line 6: -- Create a mirror image of QA_RESULTS into QA_BIS_RESULTS for

2: /* $Header: qltbisb.plb 115.19 2002/11/27 19:22:13 jezheng ship $ */
3:
4:
5: --
6: -- Create a mirror image of QA_RESULTS into QA_BIS_RESULTS for
7: -- BIS reporting purpose. QA_BIS_RESULTS is also called a
8: -- Summary Table. Not all columns of QA_RESULTS are selected.
9: -- Only those that BIS reports on will be included.
10: --

Line 8: -- Summary Table. Not all columns of QA_RESULTS are selected.

4:
5: --
6: -- Create a mirror image of QA_RESULTS into QA_BIS_RESULTS for
7: -- BIS reporting purpose. QA_BIS_RESULTS is also called a
8: -- Summary Table. Not all columns of QA_RESULTS are selected.
9: -- Only those that BIS reports on will be included.
10: --
11: -- There are two methodologies for this mirroring process.
12: -- One is a complete rebuild where the summary table is first

Line 22: -- This means deleted records in QA_RESULTS will appear in the

18: -- It is updated in both complete rebuild and incremental refresh.
19: --
20: -- **OBSOLETE**
21: -- The incremental refresh method does not take care of deletion.
22: -- This means deleted records in QA_RESULTS will appear in the
23: -- summary table, and consequently, in the BIS Report. The current
24: -- strategy is to modify QLTRSMDF/QLTRSINF so that when a row is
25: -- deleted from direct data entry, the corresponding row from
26: -- QA_BIS_RESULTS will be deleted as well.

Line 28: -- Change of status in QA_RESULTS, however, will be taken care of.

24: -- strategy is to modify QLTRSMDF/QLTRSINF so that when a row is
25: -- deleted from direct data entry, the corresponding row from
26: -- QA_BIS_RESULTS will be deleted as well.
27: --
28: -- Change of status in QA_RESULTS, however, will be taken care of.
29: -- There is a status column in QA_RESULTS which can be set to 1
30: -- to indicate an invalid rows. Those rows with status=1 will
31: -- not be included in the summary table. When the status is
32: -- updated to other values, as long as the qa_last_update_date is

Line 29: -- There is a status column in QA_RESULTS which can be set to 1

25: -- deleted from direct data entry, the corresponding row from
26: -- QA_BIS_RESULTS will be deleted as well.
27: --
28: -- Change of status in QA_RESULTS, however, will be taken care of.
29: -- There is a status column in QA_RESULTS which can be set to 1
30: -- to indicate an invalid rows. Those rows with status=1 will
31: -- not be included in the summary table. When the status is
32: -- updated to other values, as long as the qa_last_update_date is
33: -- also correctly updated, this row will be included in the next

Line 132: -- deleted from qa_results). This procedure should be called only

128: PROCEDURE delete_update_history IS
129: --
130: -- Delete the audit trail in the update history table. The audit
131: -- trail stores the primary key of the purged records (i.e. those
132: -- deleted from qa_results). This procedure should be called only
133: -- by complete rebuild or by procedure delete_purged_rows.
134: --
135: BEGIN
136: DELETE

Line 146: -- Delete those records that have been deleted from qa_results.

142:
143:
144: PROCEDURE delete_purged_rows IS
145: --
146: -- Delete those records that have been deleted from qa_results.
147: --
148: BEGIN
149: DELETE
150: FROM qa_bis_results qbr

Line 164: -- QA_RESULTS have been modified since last_refresh.

160:
161: PROCEDURE delete_updated_rows IS
162: --
163: -- Delete those rows in BIS Summary Table whose counterpart in
164: -- QA_RESULTS have been modified since last_refresh.
165: --
166: -- Notes on efficiency:
167: -- . QA_RESULTS must have either an index on qa_creation_date
168: -- or an index on qa_last_update_date (preferrable)

Line 167: -- . QA_RESULTS must have either an index on qa_creation_date

163: -- Delete those rows in BIS Summary Table whose counterpart in
164: -- QA_RESULTS have been modified since last_refresh.
165: --
166: -- Notes on efficiency:
167: -- . QA_RESULTS must have either an index on qa_creation_date
168: -- or an index on qa_last_update_date (preferrable)
169: --
170: -- . QA_BIS_RESULTS must have a unique index on occurrence.
171: --

Line 182: FROM qa_results qr

178: DELETE
179: FROM qa_bis_results qbr
180: WHERE occurrence IN (
181: SELECT occurrence
182: FROM qa_results qr
183: WHERE qr.qa_last_update_date < g_current_datetime AND
184: g_last_refresh BETWEEN
185: qr.qa_creation_date AND qr.qa_last_update_date);
186: commit;

Line 270: -- Construct a SQL statement that selects from QA_RESULTS and

266:
267:
268: PROCEDURE construct_summary_table(s in out NOCOPY varchar2) IS
269: --
270: -- Construct a SQL statement that selects from QA_RESULTS and
271: -- format it so that the results can be directly inserted into
272: -- the BIS Summary Table after putting in WHO information.
273: --
274: -- The final sql statement looks like this:

Line 295: -- qa_results qr

291: -- decode(qr.plan_id, 120, qr.CHARACTER2 ...) quantity_defective,
292: -- qr.qa_creation_date,
293: -- qr.qa_last_update_date
294: -- FROM
295: -- qa_results qr
296: -- WHERE
297: -- (qr.status is null or qr.status = 2)
298: -- and qr.qa_last_update_date < :today
299: --

Line 342: 'FROM qa_results qr ' ||

338: construct_decode('qr', quantity_defective_char_id, s);
339: s := s || ' quantity_defective,' ||
340: 'qr.qa_creation_date,' ||
341: 'qr.qa_last_update_date ' ||
342: 'FROM qa_results qr ' ||
343: 'WHERE (qr.status is null or qr.status = 2) ' ||
344: 'and qr.qa_last_update_date < :today';
345:
346: END construct_summary_table;

Line 545: -- The records in QA_RESULTS that have been modified since the

541:
542: FUNCTION incremental_rebuild RETURN number IS
543: --
544: -- Rebuild the BIS Summary Table by incremental refresh method.
545: -- The records in QA_RESULTS that have been modified since the
546: -- previous refresh datetime will be inserted into the BIS
547: -- Table. Two kinds of records in QA_RESULTS will be processed,
548: -- those that are new and those that have been updated.
549: --

Line 547: -- Table. Two kinds of records in QA_RESULTS will be processed,

543: --
544: -- Rebuild the BIS Summary Table by incremental refresh method.
545: -- The records in QA_RESULTS that have been modified since the
546: -- previous refresh datetime will be inserted into the BIS
547: -- Table. Two kinds of records in QA_RESULTS will be processed,
548: -- those that are new and those that have been updated.
549: --
550: -- Notes on efficiency:
551: -- . QA_RESULTS should have an index on qa_last_update_date.

Line 551: -- . QA_RESULTS should have an index on qa_last_update_date.

547: -- Table. Two kinds of records in QA_RESULTS will be processed,
548: -- those that are new and those that have been updated.
549: --
550: -- Notes on efficiency:
551: -- . QA_RESULTS should have an index on qa_last_update_date.
552: --
553: -- Return a SQL error code. 0 indicates no error.
554: -- bso
555: --

Line 624: -- This procedure is used when a row is deleted from qa_results.

620:
621:
622: PROCEDURE delete_log(x_occurrence number) IS
623: --
624: -- This procedure is used when a row is deleted from qa_results.
625: -- Called by QLTRES.Q_RES_PRIVATE.delete_row.
626: --
627: BEGIN
628: --

Line 694: -- Then mirror all rows in QA_RESULTS that satify this

690: -- refresh time. All rows updated at or after current_date
691: -- will be excluded in this rebuild. They will be mirrored
692: -- in the next rebulid.
693: --
694: -- Then mirror all rows in QA_RESULTS that satify this
695: --
696: -- last_refresh <= qr.qa_last_update_date < current_date
697: --
698: g_current_datetime := qltdate.get_sysdate;