Search Results qa_ahl_mr




Overview
Explore in AI Chat

Overview

The APPS.QA_PLAN_ELEMENT_API package body provides the core programmatic interface for creating, maintaining, and interrogating quality plan elements and specification characteristics within Oracle EBS Quality Management. Its principal role is to encapsulate the validation logic, datatype resolution, and cache management required when a QA plan element is associated with a specification characteristic (QA_SPEC_CHARS) or a plan characteristic (QA_PLAN_CHARS). The package is classified as an API in the ETRM 12.2.2 repository and resides in the APPS schema, meaning it is callable from forms, concurrent programs, and custom extensions without additional grants.

A significant portion of the package is devoted to performance-oriented internal caching. As documented in the source header, record types qa_spec_char_rec and qa_plan_char_rec were introduced under Bug 3769260 to store only the relevant columns of QA_SPEC_CHARS and QA_PLAN_CHARS rather than selecting all columns. These records populate the qa_spec_chars_table and companion plan cache, allowing repeated lookups during an element transaction to be served from PL/SQL memory instead of triggering redundant SQL.

Key Procedures and Functions

  • FETCH_QA_SPEC_CHARS — the entry point most commonly searched for by developers. It retrieves specification characteristic rows into the internal cache table, applying the narrowed column list defined by qa_spec_char_rec.
  • FETCH_QA_PLAN_CHARS and REFETCH_QA_PLAN_CHARS — populate and refresh the QA plan characteristic cache. The refetch variant supports cache invalidation when underlying plan data changes mid-session.
  • KEYFLEX, NORMALIZED, DERIVED, HARDCODED, and PRIMITIVE — collectively these support the datatype and value-source classification used by Quality element definitions, distinguishing key flexfield-derived values, normalized values, derived calculations, hardcoded constants, and primitive datatypes.
  • VALUES_EXIST, EXISTS_QA_PLAN_CHARS, SQL_VALIDATION_EXISTS — existence and validation checks used before insert or update of element definitions.
  • ELEMENT_IN_PLAN and ELEMENT_IN_SPEC — membership tests confirming whether a given element is associated with a plan or a specification.
  • GET_ACTUAL_DATATYPE and GET_ELEMENT_DATATYPE — resolve the effective datatype of an element, accounting for the actual value stored versus its declared type.
  • GET_SPEC_LIMITS and GET_LOW_HIGH_VALUES — return specification tolerance boundaries (target, upper/lower spec, reasonable, and user-defined limits) for a characteristic.
  • GET_DEPARTMENT_ID, GET_JOB_ID, GET_PRODUCTION_LINE_ID — contextual accessors resolving organizational and manufacturing context for an element.

Tables Accessed

The package reads and writes the quality plan base tables QA_PLAN_CHARS and QA_SPEC_CHARS through the cached record types. Manufacturing and process context is supplied by GME_BATCH_HEADER, GME_BATCH_STEPS, GME_BATCH_STEP_ACTIVITIES, GME_BATCH_STEP_RESOURCES, GME_PROCESS_PARAMETERS, and GMP_PROCESS_PARAMETERS. Inventory context is drawn from MTL_ITEM_REVISIONS, MTL_LOT_NUMBERS, MTL_MATERIAL_STATUSES, and MTL_PARAMETERS. Installed-base and service context comes from CSI_ITEM_INSTANCES, CS_INCIDENTS, and CSD_REPAIRS. Party data is referenced via HZ_PARTIES, and task references via JTF_TASKS_B.

Usage Notes

QA_PLAN_ELEMENT_API is referenced by 22 other packages, indicating it is a foundational dependency for higher-level Quality APIs rather than a terminal user-facing routine. It is typically invoked from the Quality Management plan and specification forms during element definition, from concurrent programs that validate or migrate plan data, and from custom PL/SQL that must resolve element datatypes or specification limits. Because the API maintains session-level caches, callers should invoke the refetch variants when underlying plan or specification data may have been modified by another session. All calls should be made in the APPS schema context, and the standard EBS API conventions for error handling via the FND message stack apply.