Search Results create_prepayment

Overview

AR_PREPAYMENTS_PUB is a public PL/SQL package in the Oracle EBS Receivables (AR) module. Its principal business function is to create prepayment receipts and place them on prepayment account, thereby establishing a customer credit balance that can later be applied against invoices or used to fund future transactions. The package body is identified by its RCS header, which lists a version lineage beginning with file ARPPAYAB.pls version 120.12.12010000.2, dated 30-SEP-2008. The package is owned by APPS and is classified as a PUB (public) API, meaning it is intended for supported external invocation by other Oracle EBS components and by customer-written extensions rather than as an internal-only module.

The body opens with a block of package global constants that map ETRM message levels to FND_MSG_PUB constants — G_MSG_UERROR (unexpected error), G_MSG_ERROR, G_MSG_SUCCESS, and the three debug levels G_MSG_HIGH, G_MSG_MEDIUM, and G_MSG_LOW. A private PG_DEBUG flag is initialized from the profile option AFLOG_ENABLED, which governs diagnostic logging behavior. These conventions are typical of Oracle's public API architecture, which standardizes error reporting through the FND message stack and supports runtime debugging via profile-controlled logging.

Key Procedures and Functions

Two program units are documented for this package in the ETRM metadata for Release 12.2.2:

• CREATE_PREPAYMENT — The primary public procedure. Its documented description is to create a prepayment receipt and put it on prepayment. Parameters are not enumerated in the available metadata; however, inline modification history annotations recorded in the package body indicate that the procedure validates the customer bank account identifier and raises an error when a NULL value is supplied (Bug 2315864), and that a forward-port correction was incorporated for Bug 3230122 via Bug 3220078. The procedure returns nothing, consistent with the standard Oracle API convention of returning status and messages through OUT parameters and the FND message stack rather than a function return value.
• GET_INSTALLMENT — A documented companion program unit, presumably used to retrieve installment or payment schedule information associated with prepayment activity. The available excerpt does not describe its parameters or internal logic.

No other procedures or functions are documented for this package. Authors of custom code should treat the parameter signatures as defined by the released package specification against which they compile, rather than inferring them from this summary.

Tables Accessed

The package reads and writes a set of Receivables, Payments, and Trading Community Architecture tables through APPS synonyms. The Receivables transactional core includes AR_CASH_RECEIPTS and AR_CASH_RECEIPTS_ALL (the receipt header and its multilingual/all-organization view), AR_CASH_RECEIPT_HISTORY (receipt status and workflow history), AR_RECEIVABLE_APPLICATIONS and AR_RECEIVABLE_APPLICATIONS_S1 (application of receipts to transactions and its sequence), AR_PAYMENT_SCHEDULES (installment-level balances), AR_RECEIPT_METHODS, and AR_RECEIPT_CLASSES (receipt classification, which determines prepayment behavior).

Bank account validation and lookup draw on AP_BANK_ACCOUNTS, CE_BANK_ACCOUNTS, and HR_ALL_ORGANIZATION_UNITS. Customer and party data are sourced from HZ_CUST_ACCOUNTS, HZ_CUST_SITE_USES, HZ_PARTIES, and HZ_ORGANIZATION_PROFILES. The use of these HZ and CE tables reflects the Release 12 architecture in which customer, party, and bank data were consolidated outside the legacy AR-only tables; a prepayment cannot be created without a valid, active customer bank account, which explains the NULL-validation behavior noted in the CREATE_PREPAYMENT change history.

Usage Notes

AR_PREPAYMENTS_PUB is a public API invoked programmatically rather than through direct table manipulation. Its typical callers include Receivables forms and concurrent programs that process prepayments, other Oracle EBS packages — the ETRM metadata records that this package is referenced by three other packages — and customer-written PL/SQL extensions that need to create prepayments in a supported manner. Because the package writes to core Receivables tables, callers must supply valid customer, customer bank account, receipt method, and receipt class information, and must honor the error raised when the customer bank account identifier is NULL.

Standard invocation practice for Oracle public APIs applies: initialize the FND message stack, execute CREATE_PREPAYMENT within a properly managed transaction, inspect the message stack for errors, and commit only after confirming success. Organizations migrating from Release 12.1.1 to 12.2.2 should note that this package body carries file version 120.12.12010000.2 from 2008 and is therefore shared between the two releases; the documented signature set is unchanged across them.