Search Results arp_distributions_pkg




Overview
Explore in AI Chat

Overview

ARP_DISTRIBUTIONS_PKG is a PL/SQL package body owned by the APPS schema in Oracle E-Business Suite Release 12.1.1 and 12.2.2. It encapsulates the core database operations for the AR_DISTRIBUTIONS entity, the Receivables table that stores the accounting distribution lines generated for transactions, receipts, adjustments, and other subledger events. The package provides a standardized, reusable layer through which Oracle Receivables and dependent modules create, maintain, and query distribution records without issuing ad hoc SQL against the underlying tables. Because the package body is reported as VALID in the ETRM metadata, it is compiled and active in the environment from which the documentation was extracted.

The package is classified as OTHER in the documented API classification, meaning it is not published as a formally supported public API. Nevertheless, the metadata records that ARP_DISTRIBUTIONS_PKG is referenced by eleven other database objects, confirming that it functions as a shared internal service component within the Receivables schema rather than a standalone utility.

Key Procedures and Functions

The ETRM documentation lists eight procedures and functions in the package body. The following describes their purpose based on their documented names and standard EBS row-handling conventions:

  • INSERT_P — Inserts a new distribution record into AR_DISTRIBUTIONS, populating the accounting columns and audit fields.
  • UPDATE_P — Updates an existing distribution row, typically to reflect changes in amounts, accounts, or posting status.
  • DELETE_P — Removes a distribution record from the table.
  • LOCK_P — Acquires a row-level lock on a distribution record, typically with a wait, to serialize concurrent modifications.
  • FETCH_P — Retrieves a distribution record by its primary key or another documented identifier.
  • FETCH_PK — Performs a primary-key-based fetch, returning the distribution row for a supplied key.
  • LOCK_FETCH_PK — Combines a primary-key fetch with a locking read, selecting the row FOR UPDATE with a wait.
  • NOWAITLOCK_FETCH_PK — The non-blocking variant of the above; it fetches and locks the row using FOR UPDATE NOWAIT, failing immediately if the row is already locked rather than waiting.

No parameter lists are documented in the ETRM metadata, and none are inferred here. The naming pattern is consistent with the standard Oracle Forms server-side row-locking paradigm, in which LOCK, FETCH, and combined LOCK_FETCH operations back the block-level locking behavior of an associated form.

Tables Accessed

The package references the following objects through APPS synonyms, as recorded in the dependency documentation:

  • AR_DISTRIBUTIONS — The primary entity table; all insert, update, delete, and fetch operations target this table.
  • AR_DISTRIBUTIONS_S — The corresponding sequence used to generate primary keys for new distribution rows.
  • AR_SYSTEM_PARAMETERS — Read to obtain Receivables system-level configuration, such as accounting and currency settings that influence distribution processing.
  • DUAL — Used for single-row evaluations and sequence access.

The package body additionally depends on the APP_EXCEPTION and FND_MESSAGE packages for error handling and message retrieval, ARP_STANDARD for shared Receivables utilities, and FND_PROFILE for profile option lookups.

Usage Notes

ARP_DISTRIBUTIONS_PKG is an internal implementation component rather than a documented public API. Its procedures are typically invoked from Oracle Forms-based Receivables windows, concurrent programs, and other PL/SQL packages that need to persist or retrieve distribution lines. The presence of both blocking and NOWAIT lock-fetch variants indicates the package supports interactive form sessions, where lock contention must be surfaced to the user immediately, as well as batch processes that can afford to wait for a lock. Customizations should avoid calling this package directly; developers requiring supported access to distribution data should use the corresponding Receivables public APIs or the documented open interfaces instead.