Results for “spec_assignment_type”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

QA_ERES_PLANS_V is an Oracle EBS Quality (QA) schema view owned by APPS that consolidates all electronic records plans defined in the E-Business Suite. It is a denormalized reporting view: although the driving entity is QA_PLANS, the view enriches each plan row with decoded lookup meanings, organization identifiers, and internal ID values so that consumers do not need to join multiple lookup and organization tables themselves. The description in the ETRM metadata, "All plans for electronic records," explains why the view is filtered and joined around ESIG_MODE and electronic-signature related lookups — every row represents a QA plan that carries electronic record/signature configuration.

The view is validated and exists alongside the QA_ERES_* family, which serves the e-records and e-signature framework in Oracle Quality. It is intended primarily for reporting and integration. External systems, custom concurrent programs, BI Publisher reports, and Oracle Discoverer/OBIA extracts query QA_ERES_PLANS_V to obtain plan metadata with human-readable meanings already resolved. Because it is a view, it is not directly updateable and should not be used as a DML target; base-table maintenance remains the responsibility of the Quality application forms and APIs.

Underlying Base Objects

The documented base objects are QA_PLANS, FND_COMMON_LOOKUPS, MFG_LOOKUPS, QA_LOOKUPS, MTL_PARAMETERS, HR_ALL_ORGANIZATION_UNITS_TL, and FND_GLOBAL. The core table QA_PLANS supplies plan attributes such as PLAN_ID, NAME, DESCRIPTION, PLAN_TYPE_CODE, EFFECTIVE_FROM, EFFECTIVE_TO, SPEC_ASSIGNMENT_TYPE, TEMPLATE_PLAN_ID, JRAD_DOC_VER, and ESIG_MODE. FND_COMMON_LOOKUPS is outer-joined on LOOKUP_TYPE = 'COLLECTION_PLAN_TYPE' and APPLICATION_ID = 250 to derive the plan type meaning and description; MFG_LOOKUPS decodes SPEC_ASSIGNMENT_TYPE through lookup type 'QA_PLAN_SPEC_TYPE'; and QA_LOOKUPS resolves ESIG_MODE via lookup type 'QA_ERES_RESULT_TYPE'. MTL_PARAMETERS provides ORGANIZATION_CODE, HR_ALL_ORGANIZATION_UNITS_TL supplies the organization name filtered by USERENV('LANG'), and FND_GLOBAL is referenced indirectly for environment context. All joins are outer joins, so plans with unresolved lookups are still returned with NULL meanings.

Key Columns

• PLAN_ID, ORGANIZATION_ID, NAME, DESCRIPTION — Primary identifier, owning inventory organization, and descriptive fields of the plan.
• PLAN_TYPE_CODE, PLAN_TYPE_MEANING, PLAN_TYPE_DESCRIPTION — The raw collection plan type code and its decoded values from FND_COMMON_LOOKUPS. The presence of PLAN_TYPE_MEANING is precisely what users querying "plan_type_meaning" are looking for.
• SPEC_ASSIGNMENT_TYPE, SPEC_ASSIGNMENT_MEANING — Specification assignment type code and its MFG_LOOKUPS meaning.
• EFFECTIVE_FROM, EFFECTIVE_TO — Validity window of the plan.
• ESIG_MODE, ESIG_MODE_MEANING — Electronic signature mode code and its QA_LOOKUPS meaning; central to the e-records purpose of the view.
• TEMPLATE_PLAN_ID, JRAD_DOC_VER — Source template plan and JRAD document version metadata.
• ORGANIZATION_CODE, ORGANIZATION_NAME — Inventory organization code and organization unit name.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–15 — Descriptive flexfield columns carried directly from QA_PLANS.
• Audit columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The most frequent scenario is retrieving the decoded plan type for a given plan or organization, which is exactly what the "plan_type_meaning" search implies:

• List all plans and their meanings for an organization:
  SELECT name, plan_type_meaning, esig_mode_meaning FROM qa_eres_plans_v WHERE organization_id = :org_id;
• Find plans of a specific type:
  SELECT plan_id, name FROM qa_eres_plans_v WHERE plan_type_code = 'COLLECTION';
• Identify currently effective plans:
  SELECT name, effective_from, effective_to FROM qa_eres_plans_v WHERE SYSDATE BETWEEN effective_from AND effective_to;
• Audit electronic signature configuration across the enterprise:
  SELECT organization_code, name, esig_mode_meaning FROM qa_eres_plans_v ORDER BY organization_code, name;

Because all lookups are outer-joined, reports should handle NULL meanings gracefully. Queries should additionally filter by organization when used in multi-org contexts, since the view is not automatically restricted by the current organization in the same manner as a secured transactional entity.