Search Results okl_validation_results_b




Overview
Explore in AI Chat

Overview

The OKL_VALIDATION_RESULTS_B table is a core operational table within the Oracle Leasing and Finance Management (OKL) module of Oracle E-Business Suite, available in both 12.1.1 and 12.2.2. Its documented purpose is to store the results of validations performed against various business objects in the leasing lifecycle. As leasing contracts, assets, and associated entities are processed, the application runs validation routines that confirm whether each object satisfies the required business rules. The outcome of each such check is persisted here, giving the module an auditable record of what passed, what failed, and why.

The table resides in the OKL schema and contains 27 documented columns. The ETRM relationship analysis classifies this object heuristically as a standalone Data Vault model. In practice, this suggests it could be modeled as a satellite-like entity attached to the validated business object, since it captures descriptive validation outcomes rather than defining a transactional hub or forming a link between two hubs. Practitioners should treat this classification as a modeling suggestion rather than a strict constraint.

Key Information Stored

The table is anchored by a surrogate primary key, ID, which is also backed by the unique index OKL_VLR_PK. A separate unique index, OKL_VLR_UC1, is defined on the same ID column, confirming it as the single documented business-key candidate. The remaining columns fall into distinct functional groups:

This structure lets the table record not only which object failed validation, but the exact rule, result, and any supplementary descriptive attributes needed for diagnosis.

Common Use Cases and Queries

The most frequent use case is diagnosing why a leasing contract or associated object could not proceed. Developers and support analysts query failed validations by parent object:

  • SELECT VALIDATION_ID, RESULT_CODE FROM OKL_VALIDATION_RESULTS_B WHERE PARENT_OBJECT_CODE = :code AND PARENT_OBJECT_ID = :id;
  • Reporting on validation pass/fail rates across objects using GROUP BY on RESULT_CODE.
  • Auditing historical validation activity for a given object by ordering on CREATION_DATE.
  • Joining the DFF attribute columns for customer-specific reporting or integration extracts.

Because the table is append-and-update oriented and keyed by ID, it can also be used to monitor re-validation events over time.

Related Objects

As a standalone object, OKL_VALIDATION_RESULTS_B does not participate in documented foreign-key relationships to other tables. Its parent linkage is expressed through the generic PARENT_OBJECT_CODE and PARENT_OBJECT_ID columns, which reference business objects across the OKL module rather than a single physical parent. The most significant logical associations are:

  • OKL_VALIDATION_DEFINITIONS_V / OKL_VALIDATION_HEADERS — joined via VALIDATION_ID to retrieve rule definitions.
  • OKL_CONTRACTS and its base tables — matched through PARENT_OBJECT_CODE/PARENT_OBJECT_ID when the validated object is a lease contract.
  • OKL_ASSETS — when validation is performed against leased assets.
  • OKL_LEASES and related transaction tables — for validation results tied to lease origination.
  • Standard FND lookup views — used to decode RESULT_CODE and ATTRIBUTE_CATEGORY values.

Integrations and custom reports should resolve the parent object dynamically using PARENT_OBJECT_CODE rather than assuming a fixed join path.