Search Results qa_validation_api




Overview
Explore in AI Chat

Overview

QA_VALIDATION_API is a PL/SQL package in the APPS schema that provides the central validation engine for Oracle Quality data in Oracle E-Business Suite. Its principal responsibility is to evaluate quality results, plan elements, and collection records against the rules defined in a quality plan before those records are committed or processed further. The package encapsulates the logic that determines whether a user-entered or system-generated value satisfies the constraints, action triggers, and character definitions configured on a quality plan.

The package is classified as an API in the ETRM metadata for release 12.2.2 and is also present and valid in 12.1.1. It depends only on the standard SYS.STANDARD package, and it exposes fifteen documented procedures and functions that validate rows, normalize identifiers, produce error messages, and manage validation status flags. Because it is called by result-entry, specification-result, workflow, and Enterprise Asset Management modules, QA_VALIDATION_API acts as the shared validation kernel for the Oracle Quality application.

Key Procedures and Functions

  • VALIDATE_ROW — Validates a single collection row, applying plan element rules to the supplied data.
  • VALIDATE_ELEMENT — Validates an individual quality plan element or characteristic value.
  • NO_ERRORS — Returns a status indicator showing whether the most recent validation produced any errors.
  • GET_ERROR_MESSAGE — Retrieves the text of the error generated by a failed validation.
  • VALIDATE_COMMENT — Validates comment or free-text entries associated with a result.
  • RESULT_TO_ARRAY — Converts a result into an array structure for downstream processing.
  • ID_TO_ARRAY — Converts identifier data into an array structure.
  • SET_VALIDATION_FLAG — Sets the validation status flag on a record.
  • SET_VALIDATION_FLAG_TXN — Sets the validation flag within a transaction context.
  • SET_VALIDATION_FLAG_SQL_VALID — Marks a validation flag following SQL-based validation.
  • BUILD_DEREF_STRING — Constructs a dereference string, typically to resolve lookup values dynamically.
  • PERFORM_SSQR_VALIDATION — Performs validation for specification/quality result processing.
  • GET_EXPORT_VO_SQL — Generates SQL used to export a validation view object.
  • PROCESSNOTENTEREDACTIONS — Processes actions for elements that were not entered.
  • GET_NORMALIZED_ID — Returns a normalized identifier for a plan element or record.

Tables Accessed

The package reads and writes quality configuration and transaction tables through APPS synonyms. Plan definitions are drawn from QA_PLANS, QA_PLAN_CHARS, QA_PLAN_CHAR_ACTIONS, QA_PLAN_CHAR_ACTION_OUTPUTS, and QA_PLAN_CHAR_ACTION_TRIGGERS, which together supply the element, action, output, and trigger rules applied during validation. QA_CHARS provides characteristic definitions, while QA_PLAN_CHAR_VALUE_LOOKUPS and QA_TXN_COLLECTION_TRIGGERS support lookup resolution and collection-trigger evaluation. Validated results are written to and read from QA_RESULTS and QA_PLAN_TRANSACTIONS. Inventory context is supplied by MTL_PARAMETERS, MTL_SECONDARY_INVENTORIES, MTL_SYSTEM_ITEMS, and MTL_SYSTEM_ITEMS_KFV, which identify the item, organization, and subinventory in scope. AD_DDL is referenced for dynamic SQL metadata support.

Usage Notes

QA_VALIDATION_API is invoked indirectly rather than directly by end users. Standard Oracle Quality flows — including the results entry forms, QA_RESULTS_API, QA_RESULTS_PUB, QA_RESULTS_WF_PKG, QA_PLAN_ELEMENT_API, and the specification-result packages QA_MQA_RESULTS and QA_SS_RESULTS — call into this package to validate data before commit. Enterprise Asset Management work-order quality checks (EAM_ASSET_OPERATION_TXN_PVT and EAM_WO_QUA_UTILITY_PVT) also depend on it. The package is referenced by eight packages in total, confirming its role as a shared dependency.

Custom code should not bypass this package when writing quality results, because skipping it may leave validation flags unset and permit invalid data to persist. The presence of transaction-aware procedures such as SET_VALIDATION_FLAG_TXN indicates that callers are expected to participate in the surrounding transaction. When extending or troubleshooting quality validation behavior, the QA_PLAN_CHAR_ACTION* tables and QA_RESULTS are the primary configuration and data points to inspect.