Search Results ar_prepayments_pub




Overview
Explore in AI Chat

Overview

AR_PREPAYMENTS_PUB is a public PL/SQL API package in the APPS schema that exposes the core business logic for creating and querying customer prepayments in Oracle Receivables. A prepayment represents an unapplied receipt taken from a customer before an order or invoice exists, which is subsequently applied against a future transaction. This package allows other Oracle E-Business Suite modules — most notably Order Management — and custom extensions to register prepayment receipts programmatically rather than through the Receivables window. It is classified as a PUB (public) API, indicating its procedures are intended for external invocation and are subject to Oracle's API stability conventions. The package is documented as VALID and is present in both 12.1.1 and 12.2.2 environments, though dependency composition can differ slightly between releases.

Key Procedures and Functions

  • CREATE_PREPAYMENT — The principal entry point for generating a prepayment receipt. It encapsulates the creation of a cash receipt that is left unapplied, handling the derivation of receipt method, bank account, and customer information and delegating the actual receipt insertion to the AR Receipt API. Because the metadata does not publish the full parameter list, integrators should treat the signature as documented by Oracle's Receivables Open Interfaces and APIs guide.
  • GET_INSTALLMENT — A retrieval routine used to fetch installment or payment schedule details associated with a prepayment or customer account. It allows callers to inspect an existing schedule line so that prepayment amounts can be validated or matched before application.

Both routines are thin orchestration layers: CREATE_PREPAYMENT wraps AR_RECEIPT_API_PUB and related validation, while GET_INSTALLMENT reads schedule data directly. No other documented procedures or functions are exposed in this package.

Tables Accessed

The package reads and writes data across the receipt, customer, and payment schedule model. Receipt records flow through AR_CASH_RECEIPTS, AR_CASH_RECEIPTS_ALL, and AR_CASH_RECEIPT_HISTORY, which together form the receipt header, distribution, and status-lifecycle storage. AR_RECEIVABLE_APPLICATIONS and AR_RECEIVABLE_APPLICATIONS_S1 hold application and adjustment lines, while AR_PAYMENT_SCHEDULES stores installment balances that prepayments will eventually offset. Receipt method and classification validation draws on AR_RECEIPT_METHODS and AR_RECEIPT_CLASSES. Banking information is sourced from AP_BANK_ACCOUNTS and CE_BANK_ACCOUNTS. Customer identification and remit-to address resolution use HZ_CUST_ACCOUNTS, HZ_CUST_SITE_USES, HZ_PARTIES, HZ_ORGANIZATION_PROFILES, and HR_ALL_ORGANIZATION_UNITS. These accesses are performed through APPS synonyms, consistent with standard EBS API design.

Usage Notes

AR_PREPAYMENTS_PUB is referenced by AR_PREPAYMENTS, OE_PREPAYMENT_PVT, and OE_PREPAYMENT_UTIL, confirming its role as the shared prepayment engine for Order Management's prepayment flows as well as Receivables itself. It is typically invoked from Order Management's prepayment processing, from concurrent programs that mass-create prepayment receipts, and from custom PL/SQL that requires a supported, upgrade-safe route to receipt creation rather than direct DML against AR_CASH_RECEIPTS. Callers should initialize the FND_API global variables and call the standard FND_MSG_PUB message stack before and after invocation, respecting the PUB contract. Because the package delegates to AR_RECEIPT_API_PUB, any profile options, receipt numbering, and accounting rules configured for standard Receivables receipts apply equally here. Oracle does not guarantee backward compatibility for undocumented internals, so customizations should call only CREATE_PREPAYMENT and GET_INSTALLMENT and must avoid direct dependency on the underlying tables listed above.