Search Results fa_mass_additions_s




Overview
Explore in AI Chat

Overview

The APPS.SPLIT_MASS_ADDITIONS_PKG package body provides the core business logic used by Oracle E-Business Suite Fixed Assets to split mass additions in Oracle EBS 12.1.1 and 12.2.2. Mass additions represent the staging area (the FA Mass Additions interface) where payables invoice lines, purchasing receipts, and other capitalized charges are gathered before they are posted to the fixed asset register. In many implementations a single mass addition line must be divided into multiple asset lines — for example, when a single invoice covers several physical assets, when a capitalized cost must be apportioned across cost centers or accounting distributions, or when partial quantities of an asset are placed in service. The SPLIT_MASS_ADDITIONS_PKG encapsulates that splitting and reversal logic so that it can be reused consistently by the Fixed Assets forms, concurrent programs, and any custom code that operates on FA_MASS_ADDITIONS.

The object is documented as an OTHER-classification API under the APPS schema and is currently VALID. It is self-contained: per the ETRM dependency data, it is not referenced by any other database object, meaning it is an entry-point package rather than an internal utility called by other packages.

Key Procedures and Functions

Three documented procedures/functions make up the public interface of this package body:

  • SPLIT_MASS_ADDITIONS — The primary routine. It accepts a source mass addition line and divides it into one or more child lines, apportioning the source line's amounts and distributions to each resulting child record. It typically orchestrates validation, determines the number of splits required, creates the child rows, and adjusts the parent line's remaining quantity or amount.
  • UNDO_SPLIT_MASS_ADDITIONS — The reversal counterpart. It removes previously created child lines and restores the original parent mass addition to its pre-split state, allowing the split operation to be backed out when it was created in error.
  • INSERT_SPLIT_CHILD — A lower-level helper that performs the actual insert of an individual child mass addition row (and its associated distribution rows) during a split operation. It is invoked internally by SPLIT_MASS_ADDITIONS for each child generated.

ETRM does not document parameter lists for these routines, so signatures should be confirmed against the deployed source in $FA_TOP before any direct call.

Tables Accessed

  • FA_MASS_ADDITIONS / FA_MASS_ADDITIONS_S — The base mass addition line table and its synonym used by the package. These hold the source line being split and the child lines created by INSERT_SPLIT_CHILD; note that the user's search term "fa_mass_additions_s" corresponds to this indexed synonym reference.
  • FA_MASSADD_DISTRIBUTIONS / FA_MASSADD_DISTRIBUTIONS_S — The distribution (accounting) lines associated with each mass addition. When a line is split, these rows must be apportioned to the child lines so that each resulting asset carries the correct accounts and amounts.
  • FND_CURRENCIES — Referenced for currency validation and conversion context, since mass additions and their distributions are currency-denominated and the split must preserve correct currency handling.
  • DUAL — Used for single-row SELECT operations (for example, sequence or system value retrieval).

The package also depends on FA_API_TYPES (record/type definitions), FND_MESSAGE and APP_EXCEPTION (error messaging and exception handling), and the standard STANDARD package.

Usage Notes

In standard Oracle EBS, mass addition splitting is exposed through the Fixed Assets "Mass Additions" form and related concurrent programs; those UI actions invoke SPLIT_MASS_ADDITIONS_PKG behind the scenes. Custom code that needs to programmatically split an interface line, or reverse a split, should call this package rather than inserting or deleting child rows directly, because it maintains the integrity of both the FA_MASS_ADDITIONS and FA_MASSADD_DISTRIBUTIONS records. All calls must be made within the APPS schema context, and standard exception handling (via APP_EXCEPTION/FND_MESSAGE) should be observed. Because the package is not called by any other database object, it is safe to treat it as a stable, supported entry point, but always verify the exact procedure signatures in the installed 12.1.1 or 12.2.2 environment before use.