Search Results tenure_name




Overview

PN_PROPERTIES_V is a reporting and integration view owned by the APPS schema in Oracle E-Business Suite, belonging to the PN (Property Manager) product family. Its status is VALID in both Release 12.1.1 and 12.2.2. The view presents a denormalized, business-friendly projection of property master records held in the PN_PROPERTIES table, enriching each row with decoded lookup meanings and territory names so that downstream reports, concurrent programs, and interfaces do not need to join to FND_LOOKUPS or FND_TERRITORIES_VL themselves. Because it exposes ROWID as ROW_ID alongside the primary key PROPERTY_ID, it can also serve as the data source for a DFF-enabled entity, allowing descriptive flexfield context and ATTRIBUTE1 through ATTRIBUTE15 columns to be surfaced directly to a form or report. The view is the principal read interface for property reference data in the PN module.

Underlying Base Objects

The documented base objects referenced by the view are PN_PROPERTIES (accessed through a synonym), PN_LOCATION_PARKS (synonym), FND_LOOKUPS (view), FND_TERRITORIES_VL (view), and the FND_GLOBAL package. PN_PROPERTIES supplies the driving rows and contributes the key business attributes: PROPERTY_NAME, PROPERTY_CODE, LOCATION_PARK_ID, ZONE, DISTRICT, COUNTRY, PORTFOLIO, TENURE, CLASS, PROPERTY_STATUS, CONDITION, ACTIVE_PROPERTY, the DFF columns, and the standard WHO audit columns (CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN). PN_LOCATION_PARKS is joined twice as PLP1 and PLP2 to resolve location park hierarchy information, permitting the view to derive OFFICE_PARK_ID/NAME and REGION_ID/NAME depending on the LOCATION_PARK_TYPE of the referenced park. FND_LOOKUPS is joined six times (aliases FNDZ, FNDP, FNDT, FNDC, FNDS, FNDD) to translate the ZONE, PORTFOLIO, TENURE, CLASS, PROPERTY_STATUS, and CONDITION codes into their MEANING values. FND_TERRITORIES_VL contributes TERRITORY_SHORT_NAME, and FND_GLOBAL supplies the session context used within the view logic.

Key Columns

  • ORG_ID, ROW_ID, PROPERTY_ID — multi-org identifier, ROWID surrogate, and primary key of the property record.
  • PROPERTY_NAME, PROPERTY_CODE — human-readable name and internal code for the property.
  • ZONE / ZONE_NAME, PORTFOLIO / PORTFOLIO_NAME, TENURE / TENURE_NAME, CLASS / CLASS_NAME, PROPERTY_STATUS / PROPERTY_STATUS_NAME, CONDITION / CONDITION_NAME — coded value and its FND_LOOKUPS meaning, ready for display.
  • LOCATION_PARK_ID, OFFICE_PARK_ID, OFFICE_PARK_NAME, REGION_ID, REGION_NAME — hierarchical location park attributes derived through the dual PN_LOCATION_PARKS joins.
  • DISTRICT, COUNTRY, TERRITORY_SHORT_NAME, DESCRIPTION — geographic and descriptive attributes.
  • ACTIVE_PROPERTY — flag indicating whether the property is active.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE15 — descriptive flexfield context and segment values.
  • WHO columns — CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN.

Common Use Cases and Queries

Typical uses include property listing reports, portfolio and zone analysis, interfaces that export property reference data to external systems, and LOV queries returning only active properties. Because all decoding is already performed, report SQL is simple. For example, to list active properties with their portfolio and class descriptions:

  • SELECT property_id, property_name, portfolio_name, class_name, property_status_name FROM pn_properties_v WHERE active_property = 'Y' ORDER BY property_name;
  • SELECT org_id, property_code, region_name, office_park_name, territory_short_name FROM pn_properties_v WHERE portfolio_name = 'Commercial';
  • SELECT property_id, attribute_category, attribute1 FROM pn_properties_v WHERE property_id = :p_property_id;

When joining this view to other PN tables, join on PROPERTY_ID rather than ROW_ID; ROW_ID is intended primarily for form block ROWID handling and DFF support. Note that FND_LOOKUPS joins may restrict rows where lookup meanings are not defined, so reports should filter or outer-join appropriately if unencoded codes must be returned.