Search Results create_criteria




Overview

FA_MASS_RET_PUB is a public PL/SQL API package in the Oracle E-Business Suite Fixed Assets module. It belongs to the family of mass transaction APIs that allow multiple asset adjustments to be processed in a single, validated operation rather than one asset at a time. The package specifically governs mass retirements — the bulk disposal of assets that share common selection criteria, such as a book, category, location, or date range. It is declared with AUTHID CURRENT_USER, meaning it executes under the privileges of the invoking user rather than the definer, which is typical for APPS-owned public APIs called from forms, concurrent programs, and custom PL/SQL.

The package header is small and focused: it exposes a single documented procedure, CREATE_CRITERIA, which builds the set of assets to be retired based on the calling application's selection rules and then creates the corresponding mass retirement records. The header comment (FAPMRLDS.pls, version 120.2) indicates it is a long-standing component carried forward across release levels, including 12.1.1 and 12.2.2.

Key Procedures and Functions

  • CREATE_CRITERIA — The sole documented procedure. It accepts a standard Oracle API parameter envelope, including p_api_version, p_init_msg_list, p_commit, p_validation_level, and p_calling_fn, together with the standard out parameters x_return_status, x_msg_count, and x_msg_data for error handling. Its central data parameter is px_mass_ret_rec, an IN OUT collection of type FA_CUSTOM_RET_VAL_PKG.mass_ret_rec_tbl_type. This record table carries the mass retirement selection and result data in and out of the procedure, allowing the caller to pass criteria and receive the resulting asset/retirement detail. The NOCOPY hints on both the record parameter and the out parameters reduce copying overhead for what may be a large collection.

Tables Accessed

The metadata lists the following APPS-synonym tables referenced by the package. Their roles align with the mass retirement workflow:

  • FA_MASS_RETIREMENTS — The primary target where mass retirement records are inserted or updated.
  • FA_MASS_TRANSACTIONS_S — The sequence-backed table tracking mass transaction identifiers.
  • FA_ADDITIONS / FA_ADDITIONS_B — The asset master tables (transactional and base), used to identify and validate assets selected for retirement.
  • FA_BOOKS / FA_BOOK_CONTROLS / FA_CATEGORY_BOOKS — Define the depreciation book context, control rules, and category-to-book associations that constrain which assets can be retired.
  • FA_CATEGORIES — Asset category definitions used by selection criteria.
  • FA_LOCATIONS — Location master used when criteria select assets by location.
  • FA_DEPRN_PERIODS / FA_FISCAL_YEAR — Depreciation period and fiscal calendar data, ensuring retirements fall within valid open periods.
  • FA_ASSET_KEYWORDS — Key flexfield (keyword) values used in asset selection.
  • FA_LOOKUPS / FA_LOOKUPS_B — Lookup values used for validation and status translation.
  • PLITBLM — A standard Oracle Applications PL/SQL table (index-by) utility, used for in-memory collection handling within the API.

Usage Notes

FA_MASS_RET_PUB is typically invoked from the Fixed Assets mass retirement functionality, either through the Assets form or a concurrent program that performs bulk retirements. It is a public (PUB classification) API, so it is a supported entry point for custom code that must retire assets in bulk — for example, integrations loading disposal files from an external system. Because CREATE_CRITERIA follows the FND_API error-handling pattern, callers should inspect x_return_status for FND_API.G_RET_STS_ERROR or G_RET_STS_UNEXP_ERROR and call FND_MSG_PUB utilities when x_msg_count exceeds zero. The collection parameter must be populated using the FA_CUSTOM_RET_VAL_PKG.mass_ret_rec_tbl_type structure. As the package is referenced by no other documented packages, it functions as a top-level entry point rather than an internal utility. Commit control is delegated to the caller via p_commit, so transaction boundaries should be managed deliberately in batch scenarios.