Search Results parent_object_code

Overview

OKL_VALIDATION_RESULTS_V is a descriptive (DML-capable) view owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It belongs to the OKL product family, Oracle Leasing and Finance Management, and is classified in the ETRM repository as a VALID object. The view consolidates the transactional and multilingual components of the validation results entity into a single, language-aware result set: validation results captured against a parent object, together with the user-facing validation message text resolved for the session language.

Functionally, the view serves as the reporting and integration layer for the validation framework in OKL. Rather than exposing the underlying base and translation tables separately, OKL_VALIDATION_RESULTS_V presents a denormalized projection in which each row pairs a validation outcome with its translated description. Consumers—concurrent programs, forms, OAF pages, BI Publisher reports, and outbound interfaces—can query a single object to determine which validations were executed on a given parent object and what the outcome was. The inclusion of the standard WHO columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) and the OBJECT_VERSION_NUMBER column indicates that the view is intended to support both audit reporting (including Oracle Business Intelligence Applications) and optimistic-locking-aware update flows through the underlying base table.

Underlying Base Objects

The view is defined over two documented base objects, both exposed to the APPS schema as synonyms:

• OKL_VALIDATION_RESULTS_B — the base (transactional) table holding one row per validation result, aliased VLR in the view definition. It supplies the ID, OBJECT_VERSION_NUMBER, the fifteen descriptive ATTRIBUTEn columns, the WHO audit columns, PARENT_OBJECT_CODE, PARENT_OBJECT_ID, VALIDATION_ID, and RESULT_CODE.
• OKL_VALIDATION_RESULTS_TL — the translation table holding the language-specific validation text, aliased VLRT. It supplies VALIDATION_TEXT.

The join in the view text is an inner equijoin on VLR.ID = VLRT.ID combined with the language predicate VLRT.LANGUAGE = USERENV('LANG'). Because OKL_VALIDATION_RESULTS_TL is a _TL table, its primary key is composed of ID and LANGUAGE; the USERENV('LANG') filter therefore guarantees exactly one translated row per base row, preventing row multiplication. The ROWID of the base table row is surfaced as ROW_ID, and the base table ID is surfaced as ID. Note that the view preserves the _B table's ID rather than exposing a separate translated identifier.

Key Columns

• ROW_ID — the ROWID of the underlying OKL_VALIDATION_RESULTS_B row, useful for direct-row addressing.
• ID — the primary key of the validation result; joins to OKL_VALIDATION_RESULTS_TL.ID.
• PARENT_OBJECT_CODE — the code identifying the entity type against which validation was performed (for example, a contract, quote, or asset object type). This is the column matched by the user's search term.
• PARENT_OBJECT_ID — the identifier of the specific instance of the parent object, used together with PARENT_OBJECT_CODE to scope results.
• VALIDATION_ID — the identifier of the validation rule or check that produced the result.
• RESULT_CODE — the machine-readable outcome of the validation (for example, pass, fail, warning).
• VALIDATION_TEXT — the translated, user-facing message text returned for the session language via USERENV('LANG').
• OBJECT_VERSION_NUMBER — optimistic locking version, supporting concurrent update semantics.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — the standard Oracle flex/descriptive columns permitting extensibility without schema change.
• WHO columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, and LAST_UPDATE_LOGIN for audit traceability.

Common Use Cases and Queries

Typical applications include diagnosing validation failures on a specific parent object, producing exception reports for a validation rule, and exporting validation outcomes to downstream systems. Because the language filter is embedded in the view, no additional language predicate is required by the caller.

Retrieve all validation results for a parent object:

• SELECT id, parent_object_code, parent_object_id, validation_id, result_code, validation_text
• FROM okl_validation_results_v
• WHERE parent_object_code = :p_object_code
• AND parent_object_id = :p_object_id;

List failures for a specific validation rule:

• SELECT parent_object_id, result_code, validation_text
• FROM okl_validation_results_v
• WHERE validation_id = :p_validation_id
• AND result_code = 'FAIL';

Audit extraction including WHO information:

• SELECT id, parent_object_code, created_by, creation_date, last_updated_by, last_update_date, validation_text
• FROM okl_validation_results_v
• WHERE creation_date >= :p_from_date;

Because OKL_VALIDATION_RESULTS_V is a key-preserved view over a single base table, inserts and updates issued against it are directed to OKL_VALIDATION_RESULTS_B; however, VALIDATION_TEXT is sourced from the _TL table and should be maintained through the appropriate translation APIs rather than through the view. Queries should filter by PARENT_OBJECT_CODE, PARENT_OBJECT_ID, VALIDATION_ID, or RESULT_CODE, and supporting indexes on those columns in the base table are leveraged by the optimizer.