Search Results express_description

Overview

APPS.ICX_RELATED_TEMPLATES_V is a reporting view in the Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 releases that exposes the relationships defined between Requisition Express templates, also known as Quick Requisition templates. It is owned by the APPS schema and is defined as a three-way self-join over the Requisition Express header table and the related-templates table, allowing consumers to resolve both the source and the related express template into their descriptive values in a single query.

The view is relevant to the user search term po_reqexpress_headers, since PO_REQEXPRESS_HEADERS is one of its two documented underlying base objects and supplies both pairs of express-name/description values returned by the view. Its role in Oracle EBS is primarily read-only reporting and integration: it is used by forms, OAF pages, and custom reports that need to display, for a given Express template, the other templates it is associated with and the nature of that association. Because it joins to the base header table twice, the view provides human-readable descriptions rather than raw code values, which simplifies presentation-layer and BI Publisher development.

Underlying Base Objects

The ETRM metadata documents two referenced base objects, both exposed through synonyms in the APPS schema:

• PO_RELATED_TEMPLATES (SYNONYM) — the driving table that stores the pairwise relationship records. It provides EXPRESS_NAME, RELATED_EXPRESS_NAME, and RELATIONSHIP_TYPE.
• PO_REQEXPRESS_HEADERS (SYNONYM) — the header table for Requisition Express templates, which supplies EXPRESS_NAME and DESCRIPTION. It is referenced twice in the view definition, aliased as PRXT and PRXT2, to resolve the source and related templates independently.

The view definition uses inner joins throughout: PRT.EXPRESS_NAME = PRXT.EXPRESS_NAME and PRT.RELATED_EXPRESS_NAME = PRXT2.EXPRESS_NAME. Consequently, a relationship row is returned only when both the source and the related Express template exist in PO_REQEXPRESS_HEADERS. Any orphaned relationship rows in PO_RELATED_TEMPLATES are silently excluded from the result set.

Key Columns

• EXPRESS_NAME — from the first PO_REQEXPRESS_HEADERS instance (PRXT); the code identifier of the source Requisition Express template.
• DESCRIPTION — from PRXT; the descriptive text of the source template (first DESCRIPTION column returned).
• RELATED_EXPRESS_NAME — from PO_RELATED_TEMPLATES (PRT); the code identifier of the associated template.
• DESCRIPTION — from the second PO_REQEXPRESS_HEADERS instance (PRXT2); the descriptive text of the related template (second DESCRIPTION column returned).
• RELATIONSHIP_TYPE — from PO_RELATED_TEMPLATES (PRT); classifies the association between the two templates, for example a master-detail or substitution-style linkage used by the Express template engine.

Note that the view exposes two columns named DESCRIPTION, distinguished only by ordinal position. Because no column aliases are applied in the view text, the first DESCRIPTION corresponds to the source template and the second to the related template.

Common Use Cases and Queries

Typical uses include validating related-template configuration during implementation, troubleshooting why an Express template does not offer the expected related options, and feeding relationship data into custom reports or conversions.

• List all relationships and their descriptions:

SELECT express_name, related_express_name, relationship_type
FROM apps.icx_related_templates_v;

• Retrieve related templates for one source template:

SELECT related_express_name, relationship_type
FROM apps.icx_related_templates_v
WHERE express_name = :p_express_name;

• Find all templates related to a given target:

SELECT express_name
FROM apps.icx_related_templates_v
WHERE related_express_name = :p_related_name;

• Group relationships by type for configuration analysis:

SELECT relationship_type, COUNT(*)
FROM apps.icx_related_templates_v
GROUP BY relationship_type;

Because the view contains only equijoins on indexed key columns, it is inexpensive to query and safe for high-volume reporting. Consumers should nonetheless resolve the duplicate DESCRIPTION column explicitly by position or by wrapping the view in an inline select that assigns aliases.