Search Results secondary_circulation




Overview

PN_FLOORS_V is a public view owned by the APPS schema in Oracle E-Business Suite, delivered as part of the PN – Property Manager product. Its documented purpose is to expose location information, specifically floors and other physical locations defined within the Property Manager location hierarchy. The view consolidates denormalized lookup meanings with raw code values and computes several occupancy-related metrics on the fly, making it suitable for reporting, inquiry screens, and downstream integration.

In release 12.1.1 and 12.2.2 the view is registered as VALID and is available to any application user with the appropriate grants. Because it is a public view rather than an API, it is read-only and intended for query access. The column SPACE_TYPE_LOOKUP_CODE — the term the user searched for — is one of the key lookup columns the view exposes, alongside its decoded meaning through the joined FND_LOOKUPS record. The view therefore serves as a convenient single source for space classification without requiring the caller to join FND_LOOKUPS manually.

Underlying Base Objects

The view text draws on the following documented objects: PN_LOCATIONS (referenced through its synonym), FND_LOOKUPS, the package PNP_UTIL_FUNC, and FND_GLOBAL. PN_LOCATIONS is the master location table in Property Manager and supplies the primary key LOCATION_ID, descriptive attributes (building, floor, alias), the DFF attribute columns, active date ranges, and all four lookup codes. FND_LOOKUPS is joined multiple times, each instance aliased to resolve a different lookup type: FLV for location type, LST for space type, FUN for function type, STD for standard type, and OCST for occupancy status. PNP_UTIL_FUNC is invoked through scalar function calls that compute vacant area, utilized capacity, floor vacancy, and secondary circulation for each location. FND_GLOBAL supplies session context (such as user and responsibility identifiers) that the utility functions rely on when resolving organization-specific data.

Key Columns

The view surfaces LOCATION_ID as the primary identifier and ROW_ID for row-level addressing. Lookup columns are exposed in paired form: the raw code (for example SPACE_TYPE_LOOKUP_CODE, LOCATION_TYPE_LOOKUP_CODE, FUNCTION_TYPE_LOOKUP_CODE, STANDARD_TYPE_LOOKUP_CODE) and its decoded meaning (SPACE_TYPE, LOCATION_TYPE, FUNCTION_TYPE, STANDARD_TYPE). Descriptive fields include LOCATION_CODE, LOCATION_ALIAS, BUILDING, FLOOR, and PARENT_LOCATION_ID, the last enabling hierarchical reconstruction of the location tree. Status and interface indicators are provided through STATUS and INTERFACE_FLAG, while the fifteen ATTRIBUTE columns plus ATTRIBUTE_CATEGORY carry the descriptive flexfield. Computed measures include VACANT_AREA, UTILIZED_CAPACITY, VACANCY, and SECONDARY_CIRCULATION. Active dating is handled by ACTIVE_START_DATE and a transformed ACTIVE_END_DATE that returns NULL for the 12/31/4712 sentinel. OCCUPANCY_STATUS_CODE defaults to 'Y' where no value is stored.

Common Use Cases and Queries

Typical scenarios include floor and space reporting, vacancy analysis, and feeding external real-estate or CAFM systems. A simple filter on space classification is the most frequent pattern:

  • SELECT location_id, location_code, building, floor, space_type_lookup_code, space_type, vacancy FROM pn_floors_v WHERE space_type_lookup_code = 'OFFICE';
  • SELECT building, floor, SUM(vacant_area) FROM pn_floors_v GROUP BY building, floor;
  • SELECT location_id, location_code, parent_location_id FROM pn_floors_v CONNECT BY PRIOR location_id = parent_location_id START WITH parent_location_id IS NULL;

Because the computed columns invoke PL/SQL functions, queries returning large result sets can be resource-intensive; restricting rows with predicates on indexed columns such as LOCATION_ID or LOCATION_CODE is advisable. Reports should also account for the NULL-normalized ACTIVE_END_DATE when applying date-range filters.