Search Results responsible_user_id




Overview
Explore in AI Chat

Overview

The PN_LEASE_DETAILS_HISTORY_V view in the APPS schema is a reporting and integration construct within the Oracle E-Business Suite PN – Property Manager module. It is shipped with a status of VALID in both EBS 12.1.1 and 12.2.2. Its purpose is to present a consolidated, read-optimized projection of lease detail records alongside their associated lease header information, the responsible user, and the pay group (invoice grouping) rule. The view is defined as a UNION ALL of the live lease details in PN_LEASE_DETAILS and historical lease detail rows in PN_LEASE_DETAILS_HISTORY, exposing a CURRENT_FLAG of 'Y' for the current (non-historical) branch. This makes the view suitable for auditing lease-detail changes, tracing lease lifecycle events, and building operational reports and interfaces that must reconcile both current and prior detail versions of a lease.

Underlying Base Objects

The ETRM metadata documents the following referenced base objects, all exposed as SYNONYMs within APPS:

  • PN_LEASE_DETAILS — the primary transaction table holding current lease detail rows.
  • PN_LEASE_DETAILS_ALL — the organization-stripped (_ALL) variant of lease details used to resolve multi-organization access.
  • PN_LEASE_DETAILS_HISTORY — stores prior/archived versions of lease detail rows, contributing the historical branch of the union.
  • PN_LEASES_ALL — the master lease header table, joined on LEASE_ID to supply lease name, number, status, and payment-term proration attributes.
  • FND_USER — the Oracle Applications user repository, joined to resolve the responsible user's display name.
  • PN_PAY_GROUP_RULES — looked up (outer join, (+)) to supply the invoice grouping rule name.

Because the view is defined as a synonym-based union rather than a stored object, it inherits the security and multi-org behavior of the underlying _ALL tables and remains dependency-managed by the PN schema.

Key Columns

The most relevant columns exposed by the view include:

Common Use Cases and Queries

Typical scenarios include reporting lease details for a specific responsible user, tracking how a lease detail changed over time, and joining lease details to invoice grouping rules. Because the column RESPONSIBLE_USER_ID is the documented alias for PLD.RESPONSIBLE_USER, queries searching for "responsible_user_id" resolve correctly against this view.

Example — list current lease details and responsible user for a given lease:

  • SELECT LEASE_NUMBER, LEASE_NAME, LEASE_DETAIL_ID, RESPONSIBLE_USER_ID, USER_NAME, CURRENT_FLAG FROM APPS.PN_LEASE_DETAILS_HISTORY_V WHERE LEASE_ID = :p_lease_id AND CURRENT_FLAG = 'Y';

Example — find all lease details assigned to a responsible user:

  • SELECT LEASE_NUMBER, LEASE_DETAIL_ID, RESPONSIBLE_USER_ID, USER_NAME FROM APPS.PN_LEASE_DETAILS_HISTORY_V WHERE RESPONSIBLE_USER_ID = :p_user_id ORDER BY LEASE_NUMBER;

Example — report current details with invoice group name:

  • SELECT LEASE_NUMBER, LEASE_DETAIL_ID, INV_GROUP_NAME FROM APPS.PN_LEASE_DETAILS_HISTORY_V WHERE CURRENT_FLAG = 'Y';

Because the view performs a UNION ALL across current and historical detail tables, callers should always filter on CURRENT_FLAG (or a specific DETAIL_HISTORY_ID IS NULL equivalent) when only live records are intended, to avoid returning duplicate historical versions of the same lease detail.