Search Results tenancy_history_id

Overview

The PN_TENANCIES_HISTORY table is a core data object within the Oracle E-Business Suite Property Manager (PN) module. Its primary function is to serve as a historical audit trail, systematically tracking all changes made to leased or subleased property locations over time. In the context of lease portfolio management, this table is critical for maintaining a complete and compliant record of tenancy modifications, enabling organizations to reconstruct the precise terms and conditions of a location's occupancy at any point in its lifecycle. It acts as the system of record for tenancy history, supporting financial audits, lease abstraction validation, and dispute resolution by providing an immutable log of changes.

Key Information Stored

The table stores a snapshot of tenancy attributes at the time of each change event. While the full column list is not detailed in the provided metadata, the foreign key relationships define its essential structure. Each record is uniquely identified by the TENANCY_HISTORY_ID primary key. Crucially, it links to the specific tenancy (TENANCY_ID) that was modified and captures the context of the change through LEASE_ID and LEASE_CHANGE_ID. The LOCATION_ID pinpoints the physical or logical space affected. Furthermore, it records the parties involved by storing references to the CUSTOMER_ID and CUSTOMER_SITE_USE_ID, which link to the Trading Community Architecture (TCA) customer and site data. Typical data points likely include historical values for area, rent, responsibility matrices, and occupancy dates, captured at the moment a lease or amendment is approved.

Common Use Cases and Queries

A primary use case is generating audit reports for a specific lease or location to show all tenancy changes in chronological order. This is vital for lease administration and financial reconciliation. Another scenario involves analyzing customer occupancy history across a portfolio. A common reporting pattern is to join this history table with current tenancy data to identify discrepancies or validate current terms. A sample SQL pattern to retrieve the change history for a lease would be:

• SELECT pnth.TENANCY_HISTORY_ID, pnth.LOCATION_ID, pnth.CUSTOMER_ID, hca.account_name, pnl.LEASE_NUM, pnlch.CHANGE_DESCRIPTION FROM PN_TENANCIES_HISTORY pnth JOIN PN_LEASES_ALL pnl ON pnth.LEASE_ID = pnl.LEASE_ID LEFT JOIN PN_LEASE_CHANGES_ALL pnlch ON pnth.LEASE_CHANGE_ID = pnlch.LEASE_CHANGE_ID JOIN HZ_CUST_ACCOUNTS hca ON pnth.CUSTOMER_ID = hca.cust_account_id WHERE pnl.LEASE_ID = :p_lease_id ORDER BY pnth.CREATION_DATE;

Related Objects

The PN_TENANCIES_HISTORY table is centrally connected to several key Property Manager and TCA entities, as documented by its foreign keys. It is a child table to PN_TENANCIES_ALL, storing the history for each active tenancy record. Changes are scoped within a specific PN_LEASES_ALL record and, optionally, a specific PN_LEASE_CHANGES_ALL amendment document. It references the precise PN_LOCATIONS_ALL affected. For customer and billing information, it integrates with the Trading Community Architecture via HZ_CUST_ACCOUNTS for the customer party and HZ_CUST_SITE_USES_ALL for the specific customer site use address.