Search Results xtr_layout_where_clause_v

Overview

XTR_LAYOUT_WHERE_CLAUSE_V is a dictionary view owned by the APPS schema in Oracle E-Business Suite, registered under the XTR (Treasury) product. It is a thin projection over the XTR_LAYOUT_WHERE_CLAUSE base object and exposes the configuration metadata that drives the layout, selection, and filtering rules applied when Treasury templates generate confirmation and client letter output. Unlike a transactional view, this object is configuration-oriented: it holds the clause text, sign-off state, and default template indicators that determine which layout elements render for a given template type and action type.

The view is significant for reporting and integration because it presents a denormalized, read-only surface over layout clause definitions without exposing the write path. External reports, conversion scripts, and diagnostics can query it to determine the active layout behavior for confirmations, counterparty letters, and other Treasury documents. The presence of the CURRENT_TEMPLATE_DEFAULT column, which corresponds directly to the user's search term "current_template_default," makes this view the standard access point for identifying which layout record is designated as the operational default.

Underlying Base Objects

The view is defined over a single referenced base object, the synonym XTR_LAYOUT_WHERE_CLAUSE, which resolves to the APPS-owned table of the same name. There is no join, aggregation, or filter in the view definition; every column in the base table is projected unchanged, so row counts and data types match the underlying table exactly. Because the view is a straight SELECT, no predicates are enforced and no row-level security is applied by the view itself. The view therefore inherits the table's indexes, constraints, and any Oracle EBS multi-org or security behavior configured at the base table level. SELECT privileges must be granted on the view (or the underlying object) to any custom schema querying it.

Key Columns

• TEMPLATE_TYPE — Classifies the layout template the clause belongs to, distinguishing document families such as confirmations versus letters.
• ACTION_TYPE — The Treasury action context in which the clause applies.
• VIEW_SUBSECTION — Identifies the subsection of the layout that the clause populates.
• CLAUSE_TEXT — The rendered clause body inserted into the generated document.
• COMMENTS — Free-text annotation for the layout clause definition.
• SIGNED_OFF — Indicates whether the clause has been formally approved for use.
• CLIENT_OR_CPARTY_LETTER — Flags whether the clause targets client-facing or counterparty correspondence.
• CURRENT_TEMPLATE_DEFAULT — Marks the record as the current default template for its template type and action context; this is the column most commonly used to resolve the active layout.
• SELECT_CLAUSE_TEXT — Stored SELECT statement fragment associated with the clause's data retrieval logic.
• WHERE_CLAUSE_TEXT — Stored WHERE predicate fragment that restricts the rows returned when the layout is evaluated.
• TEMPLATE_CREATED — Date or indicator recording when the template clause record was created.
• CONFO_OR_VIEW — Distinguishes confirmation-style output from view-style output.

Common Use Cases and Queries

The most frequent requirement is determining which layout clause is currently active as the default for a given template and action combination. The following query returns all default clauses across template types:

SELECT template_type,
       action_type,
       view_subsection,
       clause_text,
       confo_or_view
FROM   apps.xtr_layout_where_clause_v
WHERE  current_template_default = 'Y';

A narrower variant scopes the result to a single template and action type, or restricts to signed-off clauses only by adding AND signed_off = 'Y'. Analysts performing impact assessment ahead of a layout change typically extract SELECT_CLAUSE_TEXT and WHERE_CLAUSE_TEXT for every clause tied to a template type, so the generated SQL can be reviewed before deployment. Reconciliation or conversion projects compare this view against the XTR_LAYOUT_WHERE_CLAUSE table to confirm that no rows have been added or modified through unsupported paths.

For diagnostics, querying DISTINCT values of TEMPLATE_TYPE, ACTION_TYPE, and VIEW_SUBSECTION provides a quick inventory of configured layout coverage, revealing gaps where no default clause exists. When joining to other Treasury setup views, always constrain on CURRENT_TEMPLATE_DEFAULT to avoid multiplying rows through multiple clause definitions for the same template context. Because the view performs no filtering, callers remain responsible for applying the default and sign-off predicates appropriate to their reporting requirement.