Results for “pn_leases_all”

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

Overview

PN_LEASES_ALL is the master lease table in the Oracle Property Manager (PN) module of Oracle E-Business Suite, holding one row per lease agreement managed within the application. In EBS 12.1.1 and 12.2.2, Property Manager uses this table as the central repository for lease header information, spanning both real estate leases and equipment or other asset leases. The table is owned by the PN schema and is validated in the data dictionary.

From a Data Vault modeling perspective, the FK structure suggests that PN_LEASES_ALL behaves as a hub. It has a single surrogate primary key (LEASE_ID), a business key (LEASE_NUM), two modest outbound foreign keys (to FND_USER and HZ_CUST_ACCOUNTS), and a very large fan-out of child tables that reference it. That is the classic signature of a hub surrounded by satellites and links.

Key Information Stored

The table contains 21 documented columns. The most operationally significant are:

• LEASE_ID — surrogate primary key, enforced by constraint PN_LEASE_PK1 and unique index PN_LEASES_U1. All dependent tables join on this column.
• LEASE_NUM — the human-readable business key, enforced by unique index PN_LEASES_U2. This is the lease number users recognize.
• NAME — descriptive name of the lease.
• LEASE_TYPE_CODE and LEASE_CLASS_CODE — classification codes that drive processing and reporting.
• LEASE_STATUS and STATUS — current lifecycle state of the lease (for example active, expired, terminated).
• CUSTOMER_ID — foreign key to HZ_CUST_ACCOUNTS, identifying the customer/tenant on the lease.
• ADDRESS_LOCATION_ID and LOCATION_ID — the property address and internal location reference.
• PARENT_LEASE_ID — self-referencing link to a parent lease, supporting lease hierarchies.
• ABSTRACTED_BY_USER — foreign key to FND_USER, recording the user who abstracted the lease.
• CAL_START — calendar start date used by the billing and accounting engines.
• ORG_ID — operating unit column supporting multi-org partitioning.
• PAYMENT_TERM_PRORATION_RULE — governs how payment terms are prorated in the billing schedule.
• Standard audit columns CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, and LAST_UPDATE_LOGIN.

Common Use Cases and Queries

The table is routinely queried for lease inventory reporting, tenant listings, lease expiration tracking, and data extraction into subledger accounting. A typical query joins the lease to its customer identity and, optionally, to term information held in satellite tables:

SELECT l.lease_num, l.name, l.lease_status,
       l.cal_start, c.customer_name
  FROM pn_leases_all l,
       hz_cust_accounts c
 WHERE l.customer_id = c.cust_account_id
   AND l.org_id = :org_id
   AND l.lease_status = 'ACTIVE';

Because LEASE_ID is the universal join key, custom reports typically anchor on this table and outer-join to PN_LEASE_DETAILS_ALL, PN_PAYMENT_SCHEDULES_ALL, or PN_OPTIONS_ALL to add lease-term specifics. Expiration monitoring and rent-roll extracts are also common. When building interfaces or conversions, developers should always resolve LEASE_ID from LEASE_NUM rather than assuming surrogate values, since LEASE_ID is sequence-generated.

Related Objects

PN_LEASES_ALL is the parent in an extensive FK network. The most significant dependent tables, all joined via LEASE_ID, include:

• PN_LEASE_DETAILS_ALL — extended lease attributes; PN_LEASE_DETAILS_HISTORY holds prior versions.
• PN_LEASE_CHANGES_ALL — change/amendment records.
• PN_PAYMENT_TERMS_ALL and PN_PAYMENT_SCHEDULES_ALL — billing terms and generated payment schedules.
• PN_OPTIONS_ALL — renewal, purchase, and termination options.
• PN_RIGHTS_ALL — rights granted under the lease.
• PN_CONTACT_ASSIGNMENTS_ALL — tenant and landlord contact assignments.
• PN_REC_AGREEMENTS_ALL — recurring charge agreements.
• PN_VAR_RENTS_ALL — variable rent definitions.
• PN_TENANCIES_ALL — tenant occupancy records.
• HZ_CUST_ACCOUNTS and FND_USER — outbound references for the customer and abstracting user.

Any deletion or merge of a lease row must be coordinated with these children, since the Foreign Key relationships enforce referential integrity across the Property Manager schema.