Search Results transfer_single

Overview

FUN_AP_TRANSFER is a public PL/SQL package owned by the APPS schema that facilitates the transfer of transactions from Oracle Receivables (AR) into the Oracle Payables (AP) invoice interface. It is a key component of the integration between the two sub-ledgers, enabling receivables-related transactions — most notably refunds and other AP-bound adjustments — to be staged for invoice import. The package is declared with AUTHID CURRENT_USER, meaning its unqualified object references resolve according to the privileges of the invoking user, which is the standard convention for EBS application APIs that must respect the caller's operating context.

The central concern of the package is controlled, concurrent-safe movement of transaction records. Its most visible contract, expressed by the lock_and_transfer and lock_transaction functions, is to acquire an exclusive lock on a transaction, re-evaluate its status to confirm it remains eligible for transfer, and only then proceed with the transfer. This pattern prevents two concurrent processes — for example, two runs of the transfer concurrent program, or a program and an online form — from transferring the same transaction twice.

Key Procedures and Functions

The package exposes six documented entry points:

• HAS_VALID_CONVERSION_RATE — A function that validates whether a usable currency conversion rate exists for a given currency pair, exchange rate type, and exchange date. It allows the calling process to detect rate problems before attempting transfer.
• LOCK_AND_TRANSFER — The principal function. It acquires a lock on a single transaction, verifies that the transaction still holds a valid status, and transfers it to the AP interface. It returns a boolean indicating whether all three conditions succeeded.
• LOCK_TRANSACTION — This is the object of the user's search. A function that locks a transaction and tests whether it remains valid. It is the locking primitive on which the higher-level transfer logic depends, and it returns a boolean result.
• UPDATE_STATUS — A procedure that updates the status of a transaction, returning the new status as a side effect of the transfer lifecycle.
• TRANSFER_BATCH — A procedure that transfers transactions to the AP interface in batch mode, accepting the standard concurrent program errbuf and retcode OUT parameters.
• TRANSFER_SINGLE — A procedure that transfers one transaction outside of the batch driver.

Tables Accessed

The package reads and writes a well-defined set of tables through APPS synonyms. On the AR side it references FUN_TRX_HEADERS, FUN_TRX_LINES, FUN_DIST_LINES, and FUN_TRX_BATCHES — the transaction header, line, distribution, and batch structures that define the records being transferred. On the AP side it targets AP_INVOICES_INTERFACE and AP_INVOICE_LINES_INTERFACE (with their _S sequences) together with AP_SUPPLIERS and AP_SUPPLIER_SITES_ALL, which supply vendor and site data for the resulting interface rows. Supporting lookups include RA_CUSTOMER_TRX_ALL, GL_DAILY_RATES (for conversion-rate validation), GL_LEDGERS, GL_PERIOD_STATUSES, and WF_PARAMETER_LIST_T.

Usage Notes

FUN_AP_TRANSFER is not an end-user-facing API. It is invoked indirectly by the AR-to-AP transfer concurrent programs and by the internal form logic that drives transaction transfer, and it is referenced by one other package within the application. Customizations should generally call lock_and_transfer or transfer_single rather than manipulating the interface tables directly, because those entry points enforce the locking and status-validation that preserve data integrity. When diagnosing transfer failures, the boolean result of lock_transaction is the first indicator to inspect: a false return indicates that the transaction is already locked, has moved to an ineligible status, or otherwise failed validation.