Search Results get_lease_id

Overview

FA_REC_PVT_PKG1 is a private PL/SQL package body in the Oracle E-Business Suite Fixed Assets module, owned by the APPS schema. It supports the asset reclassification business process, which allows an asset to be moved from one asset category to another. Reclassification affects depreciation rules, category book assignments, and the associated transaction accounting, so the package performs a sequence of validation checks before any reclassification transaction is generated. In Oracle EBS 12.1.1 and 12.2.2, this package is classified as OTHER rather than a public API, indicating it is an internal helper invoked by other Fixed Assets programs rather than a documented interface for external integration. Its role is to validate whether a reclassification of a given asset is permitted, guard against invalid combinations such as retired assets or overlapping category changes, and enforce transaction date constraints. The package name carries the source header $Header: FAXVRC1B.pls 120.6 2009/03/27, confirming it is part of the FA reclassification (RC) source family.

Key Procedures and Functions

The documented package exposes four procedures and functions:

• VALIDATE_RECLASS_BASIC — The entry-point validation routine. It accepts an asset identifier, the old and new category identifiers, and a mass reclass request identifier, and returns a Boolean indicating whether the reclassification may proceed. It calls Check_Retirements to verify the asset is not retired in any book and has no pending retirement, then calls Validate_Category_Change to confirm the category transition is feasible. Failure messages are recorded through FA_SRVR_MSG.Add_Message, and the routine returns FALSE to halt processing.
• CHECK_RETIREMENTS — Determines whether the specified asset has been retired, or has a retirement pending, in any book. Returns a Boolean used by Validate_Reclass_Basic as a gate before category validation.
• VALIDATE_CATEGORY_CHANGE — Confirms that changing from the old category to the new category is valid. It also returns the old category type by reference through its output parameter, allowing the caller to reuse the prior category classification during processing.
• CHECK_TRANS_DATE — Verifies that a transaction date falls within a valid depreciation or accounting period, protecting the reclassification from being posted to a closed or otherwise invalid period.

All routines accept a FA_API_TYPES.log_level_rec_type logging record, and use fa_debug_pkg.add and FA_SRVR_MSG to emit debug and user-facing messages.

Tables Accessed

The package reads and validates against the following Fixed Assets tables, accessed through APPS synonyms: FA_ADDITIONS (asset master details), FA_ASSET_HISTORY (audit trail of asset changes), FA_BOOKS (asset assignment to books and depreciation details), FA_BOOK_CONTROLS (book-level controls and periods), FA_CATEGORIES (category definitions), FA_CATEGORY_BOOKS (category-to-book depreciation rule mapping), FA_DEPRN_PERIODS (open/closed depreciation periods used by Check_Trans_Date), FA_DISTRIBUTION_HISTORY (cost center distribution changes), FA_RETIREMENTS (retirement records checked by Check_Retirements), and FA_TRANSACTION_HEADERS (reclassification transaction headers). These tables support the core question: whether the asset exists, is not retired, has valid category and book configurations, and can be reclassified as of the requested transaction date.

Usage Notes

Because this is a private package, it is not intended for direct invocation by custom code. It is referenced by one other package and is typically called from the Fixed Assets reclassification form and the mass reclassification concurrent program, which drive Validate_Reclass_Basic for each candidate asset. In 12.1.1 and 12.2.2 the logic is largely unchanged, with the header revision 120.6 dated 2009 reflecting pre-12.2 code that remains compatible. Callers should not rely on the package signature; customizations should use the public FA reclassification APIs. When diagnostics are required, the FA debug logging controlled through the log_level_rec parameter can be enabled to trace validation decisions.