Search Results mass_ext_retire

Overview

APPS.FA_CUA_MASS_EXT_RET_PKG is a server-side PL/SQL package in Oracle E-Business Suite Fixed Assets that supports the Central User Administration (CUA) mass external retirement process. The package provides the processing engine behind concurrent programs that retire large volumes of externally held or externally invoiced assets across a specified asset book. Its header declares AUTHID CURRENT_USER, meaning the package executes with the privileges of the invoking user rather than the defining owner, which is relevant when concurrent managers or custom callers run the process.

In practice, the package coordinates the end-to-end lifecycle of a mass external retirement run: it drives retirement processing for a given book, maintains the running batch identifier and request context used across parallel or multi-request executions, records processing messages for audit and troubleshooting, and supplies a purge routine to remove obsolete mass retirement staging records. The most recent source revision documented in the header, FACXTREMS.pls 120.7 dated 2010, confirms the object has been stable through the 12.1.1 and 12.2.2 releases.

Key Procedures and Functions

• MASS_EXT_RETIRE — The core worker procedure. It performs mass external retirement for the specified book type code, receiving and returning an in-out batch name, and accepting parent request, total request, and request number parameters so that a single logical run can be split across multiple concurrent requests. It additionally maintains the maximum mass external retire identifier as an in-out parameter and returns success count, failure count, and a return status, allowing the concurrent manager or calling program to report outcome and restart behavior.
• PURGE — Housekeeping routine that removes historical mass external retirement data. It exposes the standard concurrent program error buffer and return code out parameters together with a log-level record parameter, defaulting the log level to the FA_API_TYPES log level record type.
• WRITE_MESSAGE — An internal logging and diagnostics helper. It accepts an asset number, book type code, mass external retire identifier, message, token, token value, application short name, database error code, and mode, allowing structured, tokenized messages to be recorded against the corresponding mass retirement record.

Tables Accessed

The package references the following tables through APPS synonyms:

• FA_MASS_EXT_RETIREMENTS and FA_EXT_INV_RETIREMENTS — the staging and external invoice retirement tables central to the mass external retirement process; these hold the rows the package creates, updates, and purges.
• FA_RETIREMENTS and FA_ASSET_HISTORY — the retirement transaction record and the asset audit trail updated when retirements are posted.
• FA_BOOKS, FA_BOOK_CONTROLS, and FA_DISTRIBUTION_HISTORY — book configuration, period control, and cost distribution data required to validate and account for the retirement.
• FA_ADDITIONS_B and FA_ASSET_INVOICES — asset definition and invoice linkage used to identify the assets being retired.
• FA_LOOKUPS, FND_CURRENCIES, and PLITBLM — lookup validation, currency conversion, and PL/SQL integer table utility usage.

Usage Notes

FA_CUA_MASS_EXT_RET_PKG is normally invoked indirectly. The most common entry point is the mass external retirement concurrent program, which supplies the book type code, batch name, parent request identifier, total request count, and request number so the run can be partitioned. Because the package is not referenced by any other documented package, custom code that needs to retire assets in bulk must call these procedures directly, taking care to initialize the in-out batch name and maximum mass external retire identifier and to interpret the returned success count, failure count, and return status. External retirement logic is highly dependent on book period status and data integrity, so the package should be exercised in a test environment first; the PURGE procedure is typically scheduled after retirement cycles to control table growth, and WRITE_MESSAGE output should be reviewed first when diagnosing failures.