Search Results okc_process_defs_tl

Overview

The OKL_VP_QACHECK_RESULTS_UV view is a user-facing (UV) database object owned by the APPS schema within Oracle E-Business Suite Release 12.1.1 and 12.2.2. It is delivered as part of the OKL – Lease and Finance Management product family. The view consolidates quality assurance (QA) check list process definitions together with the executable processing logic that the QA engine invokes. Rather than storing QA outcomes itself, it exposes the masters and processes that make up the QA check framework, enabling reporting, diagnostics, and integration.

Functionally, the view joins the translatable name and description of a check definition to its underlying PL/SQL package and procedure, and links that definition to the QA check lists on which it is configured. Because it surfaces both the display metadata and the callable routine behind each check, the view is commonly used when auditing which checks exist, how they are wired to code, and where they appear across check lists. This makes it valuable to functional and technical consultants investigating lease QA behavior, troubleshooting QA validation failures, or building reports over the QA configuration.

Underlying Base Objects

The view is defined over four APPS synonyms that resolve to underlying OKC base tables. The documented base objects are:

• OKC_PROCESS_DEFS_B — the base table holding process definitions, keyed by ID, including the package and procedure invoked by the process.
• OKC_PROCESS_DEFS_TL — the translatable table providing language-specific name, description, and comments.
• OKC_QA_LIST_PROCESSES — the association table mapping a process definition (PDF_ID) to a QA check list, along with run sequence and severity.
• OKC_QA_CHECK_LISTS_TL — the translatable table of QA check list headers.

The join logic ties PDFB.ID = PDFT.ID with PDFT.LANGUAGE = USERENV('LANG') so that the caller's session language governs which translation row is returned. PDFB.ID = QLP.PDF_ID links each process to its check list membership, and QLP.QCL_ID = QCL.ID links to the check list header. The view therefore presents a flattened, language-resolved picture of QA process configuration rather than a raw transactional log.

Key Columns

• NAME — the translated name of the check/process definition.
• DESCRIPTION — the translated description of the definition.
• COMMENTS — free-form comments maintained on the definition.
• PACKAGE_NAME — the PL/SQL package that implements the check.
• PROCEDURE_NAME — the procedure within that package invoked at run time.
• PDF_ID — the process definition identifier, the primary correlation key across the QA tables and the column users most frequently filter on.
• RUN_SEQUENCE — the order in which the process executes within the check list.
• SEVERITY — the severity assigned to the check, indicating the weight of a failure.

Common Use Cases and Queries

A frequent requirement is retrieving the code behind a specific QA process, which is addressed by filtering on PDF_ID. Because the value is exposed directly as a column, a parameterized lookup is straightforward:

• SELECT name, package_name, procedure_name, severity FROM okl_vp_qacheck_results_uv WHERE pdf_id = :p_pdf_id;
• SELECT pdf_id, name, run_sequence, severity FROM okl_vp_qacheck_results_uv ORDER BY pdf_id, run_sequence;
• Auditing which checks call a given package: SELECT pdf_id, name FROM okl_vp_qacheck_results_uv WHERE package_name LIKE 'OKL%';

These patterns support impact analysis before code changes, verification that the intended procedure is bound to a check, and configuration review of the QA check lists. As with all APPS synonyms, queries should be issued with the appropriate language context so that the correct translation row is returned.