Search Results fa_distribution_history_s

Overview

The APPS.FA_DISTRIBUTION_HISTORY_PKG package body encapsulates the core maintenance logic for the FA_DISTRIBUTION_HISTORY table, the Oracle Assets (Fixed Assets) repository that records the assignment of asset cost, depreciation, and account distributions across the various distribution lines associated with an asset. In Oracle EBS Release 12.1.1 and 12.2.2, this table forms the backbone of multi-line asset distribution tracking, enabling an asset's cost to be spread across multiple account combinations and multiple distribution sources (for example, source lines derived from Payables, Projects, or manual entry).

The package exposes a uniform set of row-level maintenance operations — insert, update, delete, lock, and reactivate — that centralize data validation, book control verification, and message handling. By doing so, it provides a single, consistent code path for any Oracle Assets form, concurrent program, or sub-program that needs to manipulate distribution history records without embedding raw DML against the base table. It depends on FA_API_TYPES, FA_STANDARD_PKG, FA_SRVR_MSG, APP_EXCEPTION, and FND_MESSAGE, reflecting the standard Oracle Assets server-side error and message framework.

Key Procedures and Functions

The documented API surface consists of five procedures, all classified as OTHER:

• INSERT_ROW — Creates a new distribution history record. It is the entry point for adding a distribution line to an asset, enforcing the standard validation and book-level checks before the physical insert.
• LOCK_ROW — Acquires a row-level lock on an existing distribution history record, typically used to serialize concurrent updates and prevent lost updates during interactive or batch processing.
• UPDATE_ROW — Modifies an existing distribution history record, applying the package's validation rules prior to persisting changes to the base table.
• DELETE_ROW — Removes a distribution history record, subject to the package's integrity and book control checks.
• REACTIVATE_ROW — Restores a previously deactivated or inactive distribution history record, an operation unique to Oracle Assets' convention of logically retiring rather than physically deleting certain records.

The procedures form a coherent CRUD-plus-lifecycle API. Parameter lists are not exposed in the documented metadata and are therefore not reproduced here.

Tables Accessed

The package operates against three documented tables, resolved through APPS synonyms:

• FA_DISTRIBUTION_HISTORY — The primary base table that holds the distribution history rows being inserted, locked, updated, deleted, or reactivated.
• FA_DISTRIBUTION_HISTORY_S — A companion sequence used to generate unique primary keys for new distribution history records. This is the object most directly implicated in the search term "fa_distribution_history_s".
• FA_BOOK_CONTROLS — The book control table, consulted to verify that the depreciation book associated with the distribution line is open and that the operation is permitted for the current accounting period.

The package also references DUAL and the STANDARD package, consistent with standard PL/SQL utility and sequence access patterns.

Usage Notes

Because the package is not referenced by any database object per the dependency listing, it is invoked explicitly by Oracle Assets application code and by the three documented referencing packages rather than through database-level triggers or views. Typical invocation channels include Oracle Assets forms (such as asset workbench distribution and assignment windows), Oracle Assets concurrent programs, and any custom PL/SQL that must maintain distribution history in a supported manner.

The recommended practice is to call the package's procedures instead of issuing direct DML against FA_DISTRIBUTION_HISTORY, so that book control validation, sequence-based key generation through FA_DISTRIBUTION_HISTORY_S, and standardized error messaging via FND_MESSAGE and FA_SRVR_MSG are consistently applied. The presence of a dedicated REACTIVATE_ROW procedure reinforces that distribution history is managed as a lifecycle rather than a transient record set, and custom integrations should account for logically retired rows when querying the base table.