Results for “pn_term_templates_v”

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

Overview

PN_TERM_TEMPLATES_V is a form-driven view owned by the APPS schema in Oracle E-Business Suite, belonging to the Property Manager (PN) product family. Its documented description is precise: it is the "form view used to enter/view term template information." Rather than serving as an analytical reporting object created for ad hoc query, this view exists to support the Term Templates form within Property Manager, exposing the denormalized and lookup-decorated data set required by that form's block and field structure. Status is VALID in both 12.1.1 and 12.2.2.

The view selects from the PN_TERM_TEMPLATES base entity and enriches it with joins to reference and party objects, producing a single row per active term template configuration. Because it is a form view, its column list is shaped by form requirements rather than by normalization goals, which is why it includes DECODE-based transformations such as DECODE(TERM.TAX_INCLUDED, 'Y', 'A', TERM.TAX_INCLUDED), resolving a domain value into a form-usable representation.

Underlying Base Objects

The documented referenced base objects indicate the view is defined over PN_TERM_TEMPLATES (accessed through a synonym) as its primary table, joined to a set of supporting objects. FND_GLOBAL and PNP_UTIL_FUNC appear as package dependencies, consistent with the standard EBS practice of resolving the current responsibility, org context, and user through FND_GLOBAL, and of applying Product Manager utility logic through PNP_UTIL_FUNC for security and organization filtering. FND_LOOKUPS supplies lookup meaning values used in form fields.

Party and customer context is supplied through HZ_CUST_ACCOUNTS, HZ_CUST_SITE_USES_ALL, and HZ_PARTIES, while supplier context comes from PO_VENDORS and PO_VENDOR_SITES_ALL. Location data is joined from PN_LOCATIONS_V. The DISTINCT keyword in the view text indicates that these joins can fan out and that the form requires one row per template, a characteristic that also matters when the view is reused for custom reporting.

Key Columns

TERM_TEMPLATE_ID is the primary key, with ROW_ID exposed for the form's row identity handling. NAME, DESCRIPTION, TERM_TEMPLATE_TYPE, and ACTIVE define the template itself. Financial and accounting defaults are carried in SET_OF_BOOKS_ID, CURRENCY_CODE, ACCRUAL_ACCOUNT_ID, PROJECT_ID, TASK_ID, EXPENDITURE_TYPE, and EXPENDITURE_ITEM_DATE. Payment terms and schedules are represented by NORMALIZE, SCHEDULE_DAY, PAYMENT_TERM_TYPE_CODE, PAYMENT_PURPOSE_CODE, and AP_AR_TERM_ID.

Party relationships map to VENDOR_ID, VENDOR_SITE_ID, CUSTOMER_ID, CUSTOMER_SITE_USE_ID, and CUST_SHIP_SITE_ID. Transaction and revenue defaults include CUST_TRX_TYPE_ID, INV_RULE_ID, ACCOUNT_RULE_ID, SALESREP_ID, DISTRIBUTION_SET_ID, RECEIPT_METHOD_ID, and LOCATION_ID. The TAX_GROUP_ID and TAX_CODE_ID columns referenced in the user's search are the tax determination attributes of the term template, paired with the derived TAX_INCLUDED flag. Standard WHO columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN) and ten ATTRIBUTE flex columns provide auditability and descriptive flexibility.

Common Use Cases and Queries

Typical scenarios include identifying which term templates are configured with a particular tax group, auditing active templates by operating unit, and tracing the accounting and receivable defaults applied when a term template is used.

• Locate templates by tax group: SELECT term_template_id, name, tax_group_id FROM ap_terms_definitions_v — for PN, use SELECT term_template_id, name, tax_group_id, tax_code_id FROM apps.pn_term_templates_v WHERE tax_group_id = :p_tax_group_id.
• List active templates with their payment terms and currency: SELECT name, currency_code, payment_term_type_code, ap_ar_term_id FROM apps.pn_term_templates_v WHERE active = 'Y'.
• Audit customer and vendor linkage: SELECT name, customer_id, customer_site_use_id, vendor_id, vendor_site_id FROM apps.pn_term_templates_v WHERE customer_id IS NOT NULL.
• Because the view includes DISTINCT and form-oriented joins, custom queries should filter on indexed columns such as TERM_TEMPLATE_ID or ACTIVE rather than performing broad scans.