Search Results update_receipt_unid_to_unapp




Overview
Explore in AI Chat

Overview

The APPS.AR_RECEIPT_UPDATE_API_PUB package body is a public, supported Oracle Receipts API in the Oracle E-Business Suite Release 12.1.1 / 12.2.2 environment. It exposes a controlled, PL/SQL-based interface for modifying attributes of existing cash receipts held in the Receivables application tables without requiring direct DML against those tables. The package is classified as a PUB (public) API within the ETRM registry, meaning Oracle intends it for external invocation by forms, concurrent programs, and custom code rather than for internal use only.

The primary business capability provided is the ability to reclassify a receipt from an unidentified state to an unapplied state. In Receivables processing, a receipt may be entered through AutoLockbox, manual entry, or other channels before the customer or transaction context is fully resolved. Once that context becomes available, the receipt must transition from unidentified to unapplied so that the application engine can subsequently apply it against open transactions. This package performs the necessary validation and updates to support that lifecycle transition. A secondary validation entry point allows callers to confirm that a given combination of customer, receipt, payment transaction extension, and customer bank account is internally consistent before attempting an update.

Key Procedures and Functions

The package exposes two documented public procedures:

  • UPDATE_RECEIPT_UNID_TO_UNAPP — The principal business procedure. It moves a receipt from the unidentified status to the unapplied status, updating the associated cash receipt records and related linkage data as required. This is the entry point corresponding to the user search term update_receipt_unid_to_unapp. Callers invoke it when identity information has been resolved and the receipt is ready to enter normal application processing.
  • VALIDATE_ID — A validation utility that accepts identifying keys for the receipt, customer, payment transaction extension, and customer bank account, and returns standard API status indicators along with a populated cash receipts row type. Internally it queries for a default BILL_TO site use and checks for null or inconsistent identifiers, returning FND_API success or error status. This procedure is typically called as a precondition to the update procedure.

Tables Accessed

The package reads and writes against the following documented APPS-synonym tables:

  • AR_CASH_RECEIPTS — The core receipt table. The update procedure modifies the receipt record to reflect the new unapplied status; VALIDATE_ID selects receipt attributes and the payment transaction extension identifier.
  • AR_RECEIPT_CLASSES — Read to determine the creation method code associated with the receipt, which governs which status transitions are permissible.
  • AR_SYSTEM_PARAMETERS — Read for Receivables system-level configuration that influences validation and processing behavior.
  • HZ_CUST_ACCT_SITES — Read to resolve the customer account site associated with the receipt's customer.
  • HZ_CUST_SITE_USES — Read to locate the active, primary BILL_TO site use, used to derive a default location when one is not supplied.

Usage Notes

Because this is a PUB API, it is the sanctioned integration point for changing receipt state from unidentified to unapplied. Typical invocations originate from Receivables forms, from concurrent programs that batch-process receipts after data resolution, or from customer-written PL/SQL that has already identified a receipt requiring reclassification. The package is referenced by two other documented packages, indicating it forms part of a wider dependency chain in Receipts processing.

Callers should observe standard Oracle API conventions: check x_return_status for FND_API.G_RET_STS_SUCCESS, inspect x_msg_count and x_msg_data for diagnostics, and commit explicitly at the appropriate transactional boundary. Direct updates to AR_CASH_RECEIPTS should be avoided, as they bypass the validation and referential logic this API encapsulates. The package body carries a version header of 120.12, reflecting its supported state across the 12.1.1 and 12.2.2 code lines.