Search Results ar_receipt_update_api_pub




Overview
Explore in AI Chat

Overview

AR_RECEIPT_UPDATE_API_PUB is a public PL/SQL API package in the APPS schema that supports controlled maintenance of Oracle Receivables cash receipts in Oracle E-Business Suite 12.1.1 and 12.2.2. It provides a supported, business-logic-aware entry point for altering receipt records and recalculating related accounting distributions, allowing receipt attributes to be changed without directly updating base tables. Its principal documented function is the conversion of unapplied cash into applied cash, referenced by the procedure name UPDATE_RECEIPT_UNID_TO_UNAPP. The package is classified as a PUB (public) API, signifying that it is intended for external invocation by other Oracle modules and by customer-written extensions, rather than being reserved for internal Receivables processing. The ETRM metadata confirms the object status as VALID and records its dependencies on FND_API (the standard Oracle Application Object Library API error-handling and messaging framework), AR_CASH_RECEIPTS_V (a receipts view), and the SYS.STANDARD package.

Key Procedures and Functions

The documented API exposes two callable units:

  • UPDATE_RECEIPT_UNID_TO_UNAPP — Performs the transition of a receipt from an unidentified or unapplied state to a fully applied state within Receivables. Because it is a public API, callers supply the receipt identifier and application details, and the package manages the associated validation, distribution creation, and accounting impact.
  • VALIDATE_ID — A validation routine that verifies the identity and suitability of a supplied record identifier before update processing proceeds. It is typically invoked internally by the main procedure but may be called directly by external code that requires pre-validation of a receipt reference.

No parameter lists are documented in the ETRM extract; callers should consult the package specification in the target instance for exact signatures before coding.

Tables Accessed

The package operates against the following tables through APPS synonyms:

  • AR_CASH_RECEIPTS — the base table storing receipt header information; the target of receipt attribute updates.
  • AR_RECEIPT_CLASSES — defines receipt class behavior, including whether receipts require remittance, confirmation, or clearing, and is consulted to determine permissible update and application processing.
  • AR_SYSTEM_PARAMETERS — supplies Receivables system-level settings and defaults that govern receipt handling.
  • HZ_CUST_ACCT_SITES — provides customer account site information used to resolve the paying party and its address for the receipt application.
  • HZ_CUST_SITE_USES — identifies the site use (for example, bill-to or ship-to) associated with the customer account site.

In addition, the package references the AR_CASH_RECEIPTS_V view, which presents receipt data combined with related application and customer information for validation and processing purposes.

Usage Notes

AR_RECEIPT_UPDATE_API_PUB is invoked through the FND_API framework, which means calling programs should check the returned API status and message stack rather than relying solely on exception handling. The ETRM metadata records that the package is referenced by two other packages, one of which is OKL_RECEIPTS_PVT — the Oracle Lease Management receipts private package. This confirms cross-module use: Lease Management calls the Receivables public API to update receipts it originates rather than writing to AR tables directly. Oracle strongly recommends this pattern for customizations. Direct DML against AR_CASH_RECEIPTS bypasses receipt class rules, accounting generation, and customer validation, and can leave Receivables in an inconsistent state. Custom code should therefore call this API, or, where a wrapper already exists, use the supported Oracle module that depends on it. Because the object is documented as VALID in both 12.1.1 and 12.2.2, behavior is expected to be consistent across those releases; however, implementations should always verify the current package specification in the target environment, since only two procedures are documented here and no parameter signatures are supplied in the ETRM extract.