Results for “addr_attribute1”

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

Overview

PN_COMPANY_SITES_V is a reporting view owned by the APPS schema within the Property Manager (PN) product family in Oracle E-Business Suite 12.1.1 and 12.2.2. It presents company site records—the organizational entities such as lessors, lessees, owners, and other parties that participate in lease and property transactions—joined to their associated address information and territory definitions. The view consolidates data drawn from PN_COMPANY_SITES and the address model exposed through PN_ADDRESSES_ALL, augmenting those core records with descriptive lookups and territory details. Its status is VALID, and it is intended for query and integration use rather than as the primary data-entry path; the underlying base tables remain the authoritative source for DML.

The object exists to spare developers and report authors from repeatedly reconstructing the multi-table join between company sites, addresses, and territories. Because it also surfaces the descriptive flexfield (DFF) columns of both the company site and its address, it is frequently used when reporting on user-defined attributes captured at either level.

Underlying Base Objects

The view definition selects from PN_COMPANY_SITES (referenced through the PN_COMPANY_SITES synonym) aliased as CSITE, and from PN_ADDRESSES_ALL (via the PN_ADDRESSES_ALL synonym) aliased as ADDR, joined on the company site's ADDRESS_ID. The documented metadata further lists FND_TERRITORIES_VL for territory validation and description, FND_LOOKUPS for translated lookup values such as LEASE_ROLE_TYPE, and the packages FND_GLOBAL and PNP_UTIL_FUNC, which supply session context (for example, user and login identifiers, or responsibility-driven values) and utility logic used within the view or its dependent lookups. The presence of these base objects confirms that the view is not a simple single-table projection; it is a curated join layer over the supported company-site and address model.

Key Columns

The view exposes the primary key COMPANY_SITE_ID together with the standard audit columns LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN, and a synthetic ROW_ID based on the base table's ROWID. Business attributes include NAME, COMPANY_ID, COMPANY_SITE_CODE, LEASE_ROLE_TYPE, ENABLED_FLAG, and ADDRESS_ID. The company-site descriptive flexfield is surfaced through ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15. Address-related columns are prefixed or carried through from the address record: ADDRESS_LINE1 through ADDRESS_LINE4, COUNTY, CITY, STATE, PROVINCE, ZIP_CODE, COUNTRY, TERRITORY_ID, plus the address flexfield columns ADDR_ATTRIBUTE_CATEGORY and ADDR_ATTRIBUTE1 through ADDR_ATTRIBUTE15. Note that a user searching on addr_attribute1 is targeting the address-level descriptive flexfield segment, distinct from the company-site-level ATTRIBUTE1 column; the two represent different contexts on different entities.

Common Use Cases and Queries

Typical uses include reporting all active company sites for a company, exporting parties with their addresses, and querying records by a specific descriptive flexfield segment. Because TERRITORY and lookup descriptions are joined in, the view is well suited to operational reports and to integration extracts that must carry human-readable role and territory values.

• List enabled sites for a company: SELECT company_site_id, name, company_site_code, lease_role_type, city, state, country FROM apps.pn_company_sites_v WHERE company_id = :company_id AND enabled_flag = 'Y';
• Search by address flexfield segment (the addr_attribute1 term): SELECT company_site_id, name, addr_attribute_category, addr_attribute1, address_line1, city FROM apps.pn_company_sites_v WHERE addr_attribute1 = :value;
• Report sites with full mailing address: SELECT name, address_line1, address_line2, city, state, zip_code, country FROM apps.pn_company_sites_v ORDER BY name;

As with any APPS-owned view, queries should be issued with fully qualified naming or a suitable synonym, and DML should be directed to the underlying PN_COMPANY_SITES and PN_ADDRESSES_ALL tables rather than through the view.