Search Results fa_masspsltfr_pkg




Overview

FA_MASSPSLTFR_PKG is an Oracle EBS Assets (Fixed Assets / FA) PL/SQL package owned by the APPS schema. It supports the Mass Transactions feature known as Mass Transfer, specifically the mass transfer of assets between depreciation books. This functionality is closely related to the Mass Copy and Mass Transfer concurrent programs, which allow a set of assets in one book to be replicated or moved into a target book. The package coordinates the batch processing of these transfers, dividing the workload across multiple parallel worker requests to improve throughput for large asset populations.

The package header carries an internal revision marker indicating it has been part of the E-Business Suite codebase since the earlier 11i releases and was maintained through the 12.1.1 and 12.2.2 code lines. It is classified as an unrestricted "OTHER" API, meaning it is not a formally published public API but is invoked internally by Oracle's own concurrent program infrastructure.

Key Procedures and Functions

  • DO_MASS_SL_TRANSFER — The core worker procedure that performs the actual mass transfer of assets for a single unit of work. It accepts the book type code, a batch name identifying the mass transfer run, and a series of identifiers relating to the parent concurrent request and its position within that request set (parent request ID, total requests, request number). It also receives the calling interface indicator, which distinguishes how the process was launched. The procedure returns or updates the maximum mass external transfer identifier, a success count, a failure count, and a return status through its output parameters. It is not overloaded; the single documented signature handles the transfer execution.
  • ALLOCATE_WORKERS — The procedure that orchestrates parallelism for a mass transfer run. Given a book type code, a batch name, and the total number of requests the parent run intends to spawn, it partitions the pending work among worker requests and manages how each worker is assigned its share. It returns a status indicator and optionally accepts a log-level record for diagnostic output. This is the procedure most commonly associated with the search term "allocate_workers," since it is the entry point for distributing transfer work across concurrent managers.
  • PURGE — A housekeeping procedure added to address bug 5364995. It removes obsolete or residual mass transfer data, using the ERRBUF and RETCODE parameters that follow the standard concurrent program calling convention. It is typically registered as or called from a concurrent program to clean up staging records.

Tables Accessed

  • FA_MASS_EXTERNAL_TRANSFERS — The primary staging table for mass transfer rows, tracking each external transfer and its identifier (referenced by the px_max_mass_ext_transfer_id parameter).
  • FA_MASS_UPDATE_BATCH_HEADERS — Stores batch header information keyed by batch name, used to associate workers with a specific mass transaction run.
  • FA_BOOKS — Provides the asset-to-book assignments that determine which assets exist in the source and target books.
  • FA_BOOK_CONTROLS — Supplies book-level control settings, including accounting and transfer rules that govern how the transfer must behave.
  • FA_ASSET_INVOICES — Referenced in relation to asset invoice and cost information tied to transferred assets.
  • DUAL and PLITBLM — Utility references for scalar evaluation and PL/SQL index-by table handling.

Usage Notes

FA_MASSPSLTFR_PKG is normally invoked indirectly rather than called directly by end users. The Mass Transfer and Mass Copy concurrent programs in the Assets responsibility ultimately drive DO_MASS_SL_TRANSFER, with ALLOCATE_WORKERS used to fan the work out across multiple child requests. Organizations that need to schedule very large book-to-book transfers may tune the number of worker requests via the concurrent program parameters that feed ALLOCATE_WORKERS. PURGE is exposed only through its dedicated concurrent program for administrative cleanup.

Because the package is classified as an unrestricted internal API and is not documented as a public interface, custom code should avoid calling it directly. Oracle does not guarantee its signature across patches, and the header revision demonstrates that it has changed over time. When extending mass transfer behavior, developers should instead work through the supported Mass Transactions APIs and concurrent programs, reserving direct calls to this package only when read-only inspection of FA_MASS_EXTERNAL_TRANSFERS and FA_MASS_UPDATE_BATCH_HEADERS is required for diagnostics or reconciliation reporting.