Search Results lock_f_ct_id

Overview

ARP_PS_PKG is the Oracle Receivables low-level API package responsible for maintaining and locking rows in the AR_PAYMENT_SCHEDULES table. Payment schedules represent the individual installments of a transaction or receipt, and every Receivables transaction (invoice, debit memo, credit memo, chargeback, deposit, guarantee, and so on) carries one or more payment schedule rows that drive aging, adjustments, collections, and cash application. The package declares AUTHID CURRENT_USER, meaning it executes with the privileges of the calling schema rather than the defining owner, and its procedures operate directly against the %ROWTYPE of AR_PAYMENT_SCHEDULES, exposing both record-based and primary-key-based entry points.

The package header shown carries a CVS revision string dating to 2002 and exposes a compact set of DML, locking, and fetch primitives rather than a single high-level business API. It is classified as OTHER in the ETRM 12.2.2 repository and is referenced by 34 other packages, which confirms its role as an internal building block consumed by higher-level Receivables APIs and forms logic.

Key Procedures and Functions

• SET_TO_DUMMY — Initializes a payment schedule record to a placeholder/dummy state, typically used to reset a %ROWTYPE variable before populating it.
• INSERT_P — Inserts a new payment schedule row and returns the generated payment_schedule_id through an OUT parameter.
• UPDATE_P — Overloaded; updates a payment schedule row identified either by a supplied record or by the payment_schedule_id, depending on which variant is invoked.
• DELETE_P — Deletes a payment schedule row by its payment_schedule_id.
• DELETE_F_CT_ID — Deletes payment schedule rows associated with a given customer_trx_id, supporting cleanup of a transaction's schedules.
• LOCK_P — Acquires a row lock on a payment schedule, keyed by payment_schedule_id, before performing a concurrency-sensitive update.
• LOCK_F_CT_ID — Acquires a lock on payment schedule rows for a given customer_trx_id. This is the procedure associated with the lock_f_ct_id search term; it isolates all payment schedules belonging to one transaction so that concurrent updates cannot interleave.
• NOWAITLOCK_P — Performs a non-blocking lock attempt by payment_schedule_id, immediately raising an exception if the row is already locked rather than waiting.
• NOWAITLOCK_COMPARE_P — Attempts a non-blocking lock and additionally compares the current amount_due_remaining against a supplied value, guarding against stale reads.
• FETCH_P — Retrieves a complete payment schedule row into an OUT record, keyed by payment_schedule_id.
• FETCH_FK_CR_ID — Fetches payment schedule rows associated with a given cash_receipt_id, returning the row through an OUT record.

Tables Accessed

• AR_PAYMENT_SCHEDULES — The primary table the package inserts, updates, deletes, locks, and fetches. Its %ROWTYPE defines the record interface for most procedures.
• AR_PAYMENT_SCHEDULES_S — The sequence used to generate new payment_schedule_id values during INSERT_P.
• RA_CUSTOMER_TRX — Referenced through the customer_trx_id that links schedules to a transaction, used by DELETE_F_CT_ID and LOCK_F_CT_ID.
• AR_CASH_RECEIPTS — Referenced by the cash_receipt_id used in FETCH_FK_CR_ID to retrieve schedules for a receipt.
• AR_SYSTEM_PARAMETERS — Consulted for Receivables setup and system options that influence processing and locking behavior.
• DUAL — Used for sequence and utility selections.

Usage Notes

ARP_PS_PKG is an internal package rather than a public integration API. It is typically invoked from within higher-level Receivables APIs, AutoInvoice and cash application logic, and Oracle Forms code that maintains payment schedules. Calls to LOCK_F_CT_ID are made before updating all schedules of a transaction so that competing sessions cannot modify the same rows concurrently. FETCH_FK_CR_ID supports cash-related processing by returning schedules tied to a receipt.

The NOWAITLOCK_* procedures are intended for flows where the caller must detect lock contention immediately and take alternative action rather than block. Because the package is referenced by dozens of other packages, custom code should not redefine or shadow these procedures. Direct invocation from custom code is technically possible given the APPS synonym, but Oracle recommends calling the documented higher-level Receivables APIs, since the signature and behavior of these internal primitives can change between releases.