Results for “layout_mode”

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

Overview

QA_PC_PLAN_RELATIONSHIP is a Quality (QA) module table in the Oracle E-Business Suite 12.1.1 and 12.2.2 schemas. It defines the hierarchical relationships between collection plans stored in QA_PLANS by recording a parent plan, a child plan, the nature of the relationship, and whether the child plan is mandatory within that relationship. In effect, it is the structural backbone that governs how parent and child plans are assembled into complex, multi-level collection plan structures used during inspection, sampling, and quality data collection.

From a Data Vault modeling perspective, the heuristic classification for this object is satellite-leaning. It holds descriptive attributes (relationship type, data entry mode, layout mode, default specifications) attached to a relationship keyed by PLAN_RELATIONSHIP_ID, rather than acting as a pure intersection (link) table. This is offered as a modeling suggestion rather than a definitive classification.

Key Information Stored

The table is composed of 14 documented columns. The most significant are:

• PLAN_RELATIONSHIP_ID — The surrogate primary key, enforced by QA_PC_PLAN_RELATIONSHIP_PK1. This identifier is also the unique-index (business-key) candidate when combined with ZD_EDITION_NAME via QA_PC_PLAN_RELATIONSHIP_U1.
• PARENT_PLAN_ID — Foreign key to QA_PLANS, identifying the higher-level plan in the hierarchy.
• CHILD_PLAN_ID — Foreign key to QA_PLANS, identifying the subordinate plan linked to the parent.
• PLAN_RELATIONSHIP_TYPE — Classifies the nature of the parent-child association.
• DATA_ENTRY_MODE — Controls how data is entered against the related plan.
• AUTO_ROW_COUNT — Governs automatic row generation for the relationship.
• DEFAULT_PARENT_SPEC — Stores default specification context inherited from the parent plan.
• LAYOUT_MODE — Determines the presentation layout of the associated plan.
• ZD_EDITION_NAME — Editioning column supporting the AD online patching / edition-based redefinition model in 12.2.x.
• Audit columns — CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN capture who created and last modified each relationship row.

Common Use Cases and Queries

Typical reporting and configuration scenarios include reconstructing the full parent-child plan tree, identifying which child plans are mandatory, and tracing which criteria or element relationships hang off a given plan relationship.

SELECT r.PLAN_RELATIONSHIP_ID,
       r.PARENT_PLAN_ID,
       r.CHILD_PLAN_ID,
       r.PLAN_RELATIONSHIP_TYPE
FROM   QA.QA_PC_PLAN_RELATIONSHIP r
WHERE  r.PARENT_PLAN_ID = :parent_plan_id;

To resolve plan names for both ends of a relationship:

SELECT pp.NAME AS parent_plan,
       cp.NAME AS child_plan,
       r.PLAN_RELATIONSHIP_TYPE
FROM   QA.QA_PC_PLAN_RELATIONSHIP r
JOIN   QA.QA_PLANS pp ON pp.PLAN_ID = r.PARENT_PLAN_ID
JOIN   QA.QA_PLANS cp ON cp.PLAN_ID = r.CHILD_PLAN_ID;

Because this table is satellite-leaning, date-effective reporting should join audit columns (LAST_UPDATE_DATE) when change history is required. In 12.2.x, queries should account for ZD_EDITION_NAME to avoid returning rows from obsolete editions.

Related Objects

• QA_PLANS — Referenced by both PARENT_PLAN_ID and CHILD_PLAN_ID; supplies the plan definitions that this table links.
• QA_PC_CRITERIA — Child table referencing PLAN_RELATIONSHIP_ID; stores criteria attached to the relationship.
• QA_PC_ELEMENT_RELATIONSHIP — Child table referencing PLAN_RELATIONSHIP_ID; stores element-level relationships tied to the plan relationship.

These three objects form the core dependency cluster around QA_PC_PLAN_RELATIONSHIP. Queries that combine them with QA_PLANS yield a complete view of collection plan hierarchy, associated criteria, and element mappings.