Search Results ar_payment_schedules_s

Overview

ARP_PS_PKG is a PL/SQL package in the APPS schema that encapsulates core data-access logic for the AR_PAYMENT_SCHEDULES table and related Receivables entities. Its name reflects its role as a "payment schedules" maintenance package, and its documented API surface consists exclusively of low-level DML primitives: insert, update, delete, lock, and fetch operations bound to specific primary key columns. In the Oracle E-Business Suite Release 12.1.1 and 12.2.2 environments, the package acts as the programmatic gateway through which other Receivables modules create and manipulate payment schedule rows — the installment records that drive aging, collections, dispute tracking, and cash application. The ETRM metadata classifies the object as OTHER rather than a public open interface, confirming that it is an internal building block consumed by Oracle's own application code rather than a documented integration point for customer extensions. Its validity status is VALID and it is referenced by 34 other packages, indicating broad internal dependency across the Receivables code base.

Key Procedures and Functions

The ETRM documentation exposes twelve procedures and functions. They divide into four functional groups.

• DML primitives: INSERT_P, UPDATE_P, and DELETE_P perform the standard insert, update, and delete operations against the payment schedules record set.
• Primary-key-targeted delete: DELETE_F_CT_ID deletes rows scoped to a customer transaction identifier, allowing callers to clear schedule lines associated with a specific transaction rather than a single schedule row.
• Locking: LOCK_P and LOCK_F_CT_ID acquire exclusive row locks, the former by the package's primary schedule key and the latter by customer transaction ID. NOWAITLOCK_P and NOWAITLOCK_COMPARE_P provide non-blocking lock acquisition variants; the COMPARE form additionally validates the fetched row against a caller-supplied value, supporting optimistic concurrency checks before an update.
• Fetch and auxiliary operations: FETCH_P retrieves a single payment schedule row by its primary key, and FETCH_FK_CR_ID retrieves rows by foreign key to a cash receipt. SET_TO_DUMMY appears to be a utility routine used to nullify or placeholder-initialize a record structure prior to population.

Parameter lists are intentionally omitted here because the ETRM extract does not document them; consumers should inspect the package specification in the target instance rather than assume a signature.

Tables Accessed

The metadata identifies six tables reached through APPS synonyms. AR_PAYMENT_SCHEDULES is the primary target and is the subject of every DML and locking routine. AR_PAYMENT_SCHEDULES_S is the corresponding sequence that supplies schedule identifiers on insert. AR_CASH_RECEIPTS is referenced for the FETCH_FK_CR_ID lookup, linking schedules back to their originating receipt. RA_CUSTOMER_TRX supports join or validation logic against the transaction header. AR_SYSTEM_PARAMETERS supplies Receivables setup values, likely for multi-organization or accounting-rule defaults, while DUAL serves as the standard single-row selection source. The package also depends on ARP_GLOBAL, ARP_STANDARD, ARP_UTIL, ARP_VIEW_CONSTANTS, ARP_DISPUTE_HISTORY, AR_MRC_ENGINE, FND_GLOBAL, FND_MESSAGE, FND_PROFILE, APP_EXCEPTION, GL_CA_UTILITY_PKG, and ARP_PS_PKG (its own specification), indicating reliance on message handling, profile lookup, multi-reporting-currency conversion, and dispute history maintenance.

Usage Notes

ARP_PS_PKG is invoked internally by Receivables forms, concurrent programs, and higher-level API packages rather than by end users directly. With 34 referencing packages, it functions as a shared persistence layer beneath transaction entry, adjustments, receipt application, and collections processing. Because locking is exposed through explicit LOCK_P, NOWAITLOCK_P, and NOWAITLOCK_COMPARE_P routines, calling code is expected to manage concurrency deliberately — acquiring a lock, validating, then updating. Customizations that bypass this package and write to AR_PAYMENT_SCHEDULES directly risk corrupting the application's own concurrency assumptions and should instead call the documented routines, observing the same lock-then-modify discipline. The package is not referenced by any external database object, underscoring its position as a leaf-level implementation detail of the Receivables schema.