Results for “pqh_template_attributes”

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

Overview

PQH_TEMPLATE_ATTRIBUTES is a transactional configuration table owned by the HR schema within the Public Sector HR (PQH) product family of Oracle E-Business Suite. It stores the list of attributes, together with their associated security levels, that are defined for each template used by the Public Sector HR framework. In practice, this table acts as the junction between the templates an administrator configures and the individual attribute definitions that govern what data may be viewed, edited, or required when the template is applied.

The ETRM metadata classifies this object as a link under a heuristic Data Vault model. This classification reflects the fact that the table resolves a many-to-many relationship: a single template can reference many attributes, and a single attribute can be reused across many templates. The link carries descriptive payload columns — notably the security-level and behavior flags — attached to the two foreign-key references.

Key Information Stored

The table contains thirteen documented columns. The most operationally significant are:

• TEMPLATE_ATTRIBUTE_ID — the surrogate primary key, unique for each attribute-to-template association, enforced by PQH_TEMPLATE_ATTRIBUTES_PK.
• ATTRIBUTE_ID — foreign key to PQH_ATTRIBUTES, identifying the attribute being associated.
• TEMPLATE_ID — foreign key to PQH_TEMPLATES, identifying the owning template.
• REQUIRED_FLAG — indicates whether the attribute must be supplied when the template is used.
• VIEW_FLAG — controls whether the attribute is visible within the template context.
• EDIT_FLAG — controls whether the attribute may be modified within the template context.
• OBJECT_VERSION_NUMBER — optimistic locking column maintained by the framework.
• ZD_EDITION_NAME — editioning discriminator, present because the table is edition-enabled in 12.2.2.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, CREATED_BY, CREATION_DATE — standard Oracle EBS audit columns tracking who created and last modified each row.

Two unique indexes serve as business-key candidates: PQH_TEMPLATE_ATTRIBUTES_PK (TEMPLATE_ATTRIBUTE_ID, ZD_EDITION_NAME) and PQH_TEMPLATE_ATTRIBUTES_UK (ATTRIBUTE_ID, TEMPLATE_ID, ZD_EDITION_NAME). The latter enforces that any given attribute is associated with a given template at most once per edition.

Common Use Cases and Queries

Typical uses include auditing which attributes a template exposes, determining whether a field is editable or required at a given point in a workflow, and generating reports of template configuration for governance review. A common query retrieves all attributes for a template:

SELECT pta.template_attribute_id, pa.attribute_name, pta.required_flag,
       pta.view_flag, pta.edit_flag
FROM   pqh_template_attributes pta, pqh_attributes pa
WHERE  pta.attribute_id = pa.attribute_id
AND    pta.template_id = :template_id
AND    pta.zd_edition_name = :edition;

Security-level reporting joins to PQH_ATTRIBUTES to resolve attribute descriptions and to PQH_TEMPLATES to identify the template name and owning business group. Administrators also use this table to diff two templates when troubleshooting inconsistent behavior between similarly configured position or assignment templates.

Related Objects

• PQH_ATTRIBUTES — referenced via PQH_TEMPLATE_ATTRIBUTES.ATTRIBUTE_ID; provides the attribute definitions and their owning security level.
• PQH_TEMPLATES — referenced via PQH_TEMPLATE_ATTRIBUTES.TEMPLATE_ID; supplies the template header and context.
• PQH_TEMPLATE_ATTRIBUTES_PK — primary-key index on TEMPLATE_ATTRIBUTE_ID and ZD_EDITION_NAME.
• PQH_TEMPLATE_ATTRIBUTES_UK — unique business-key index on ATTRIBUTE_ID, TEMPLATE_ID and ZD_EDITION_NAME.

Because these are the only documented referential relationships, dependent application logic and concurrent programs — such as those that render templates within the Public Sector HR position and assignment flows — reach this table through the two parent tables rather than through additional declared foreign keys.