Search Results pn_norm_renorm_pkg




Overview
Explore in AI Chat

Overview

PN_NORM_RENORM_PKG is an Oracle Lease and Finance Management (OLFM) utility package owned by the APPS schema. Its name reflects its core responsibility: normalization and renormalization of lease payment schedules. In the OLFM data model, lease payment schedules are stored in a set of interrelated tables that include header-level lease records, lease detail (version) records, payment schedules, payment items, and payment terms. When a lease is originated, amended, or terminated, the derived payment stream must be rebuilt so that it remains internally consistent with the current lease terms and accounting rules.

This package encapsulates that rebuild logic behind a single entry point, NORMALIZE_RENORMALIZE. It is a supporting engine rather than a user-facing API; it is invoked internally by OLFM schedule-processing components such as PN_SCHEDULES_ITEMS, which is documented as the sole package-level dependent, and by forms and concurrent programs that drive lease lifecycle events. Because it manipulates financial schedule data, it is classified in ETRM as an OTHER API — not a published, extension-oriented interface — and customizations should not call it directly without a clear understanding of its side effects.

Key Procedures and Functions

The package exposes a single documented procedure/function: NORMALIZE_RENORM_NORMALIZE — that is, NORMALIZE_RENORMALIZE. Its documented purpose is to normalize and renormalize lease schedule data. Normalization builds or validates the initial payment schedule structure for a lease and its associated payment items; renormalization performs the same operation to reconcile an existing schedule after lease terms change, so that schedule lines and payment items again align with the governing lease details and payment terms.

Parameter lists are not documented in the source metadata and are deliberately omitted here; consumers should not assume any signature. Operationally, the procedure works against a lease or lease-detail identifier supplied by the caller and drives the schedule regeneration through the OLFM tables listed below. No other public procedures or functions are documented for this package.

Tables Accessed

The package reads and writes the principal OLFM lease-financial tables, resolved through APPS synonyms:

  • PN_LEASES and PN_LEASES_ALL — the lease header, providing the contract terms that govern schedule generation and versioning.
  • PN_LEASE_DETAILS_ALL — the lease version/detail records that define the terms applicable to a specific schedule rebuild.
  • PN_LEASE_CHANGES_ALL — the recorded lease changes that trigger renormalization when existing schedule data must be reconciled.
  • PN_PAYMENT_SCHEDULES_ALL — the payment schedule header and lines produced or refreshed by the normalization process.
  • PN_PAYMENT_ITEMS_ALL and PN_PAYMENT_ITEMS_S — the individual payment items (and their sequence) generated for each schedule line.
  • PN_PAYMENT_TERMS_ALL — the payment term definitions used to derive item amounts, dates, and frequencies.
  • DUAL and PLITBLM — standard single-row and PL/SQL table constructs used for scalar evaluation and in-memory collection handling.

Writes are concentrated on PN_PAYMENT_SCHEDULES_ALL and PN_PAYMENT_ITEMS_ALL; the remaining tables are predominantly read as the basis for regeneration.

Usage Notes

PN_NORM_RENORM_PKG is invoked during lease lifecycle processing: lease booking and schedule creation, lease amendment or change application, and any operation requiring schedule lines to be rebuilt to match current terms. In Oracle EBS 12.1.1 and 12.2.2 it is called from OLFM schedule-handling code such as PN_SCHEDULES_ITEMS rather than exposed on a form button or concurrent program parameter. There is no documented standalone concurrent program.

Because the package performs destructive rebuilds of schedule and payment-item data, it should be treated as internal OLFM infrastructure. Custom code should reach it only through supported lease APIs, and any direct invocation must occur within the same transaction and commit boundaries expected by the calling OLFM component. The status VALID and its dependency on APPS synonyms indicate the package is compiled and active in the environment, but it remains undocumented as a public extension point.