Search Results ar_deposit_api_pub




Overview
Explore in AI Chat

Overview

AR_DEPOSIT_API_PUB is a public PL/SQL API package owned by the APPS schema in Oracle E-Business Suite Receivables. It provides the supported, programmatic entry point for creating and maintaining deposit transactions — customer prepayments applied against future orders or commitments — without requiring direct inserts into the underlying Receivables transaction tables. The package encapsulates the business logic required to build a deposit in RA_CUSTOMER_TRX, populate its lines in RA_CUSTOMER_TRX_LINES, associate sales credits, and attach payment-related attributes such as bank accounts, receipt classes, and receipt methods. By exposing a single, validated interface, it shields callers from the internal structure of the transactional model and ensures that deposits conform to Receivables setup and validation rules.

The package is classified as PUB (public), meaning that Oracle supports it as an integration point for customer extensions and third-party systems. It is implemented alongside a library layer, AR_DEPOSIT_LIB_PVT, which contains the private subprograms that the public package delegates to. The dependency metadata shows AR_DEPOSIT_API_PUB both references and is referenced by AR_DEPOSIT_LIB_PVT, confirming a layered design in which the public API is a thin, stable façade over internal logic. The package also depends on FND_API, the Oracle Application Object Library foundation package, which supplies the standard API return-status conventions (success, unexpected error, error) and message stack handling used across EBS product APIs.

Key Procedures and Functions

  • CREATE_DEPOSIT — The primary creation routine. It builds a new deposit transaction based on the supplied customer, transaction type, and amount information, writing the header and lines and returning the resulting transaction identifier to the caller.
  • INSERT_NON_REV_SALESCREDIT — Inserts non-revenue sales credit assignments for the deposit transaction, enabling salesperson credit to be recorded against the deposit lines.
  • SET_PROFILE_FOR_TESTING — A diagnostic helper that establishes the profile option context required to exercise the deposit API in test or development environments.
  • COPY_TRXN_EXTENSION — Copies transaction extension data (the IBY_FNDCPT_TX_EXTENSIONS records associated with payment instrument data) onto the deposit transaction, ensuring extended payment attributes are preserved.

The exact parameter lists are not reproduced here; callers should consult the package specification in the EBS instance for the accepted arguments.

Tables Accessed

The API touches both transactional and reference tables. Core transaction storage is in RA_CUSTOMER_TRX, RA_CUSTOMER_TRX_ALL, and RA_CUSTOMER_TRX_LINES, where the deposit header and its lines are written. RA_CUST_TRX_TYPES and RA_BATCH_SOURCES supply the transaction type and batch source context required during creation, while RA_CUST_TRX_LINE_SALESREPS stores the sales credit records inserted by INSERT_NON_REV_SALESCREDIT. Payment scheduling is handled through AR_PAYMENT_SCHEDULES, and payment setup is validated against AP_BANK_ACCOUNTS, AR_RECEIPT_CLASSES, and AR_RECEIPT_METHODS. Customer and party validation uses HZ_CUST_ACCOUNTS, HZ_CUST_ACCT_SITES, HZ_CUST_SITE_USES, and HZ_PARTIES. Extended payment instrument data resides in IBY_FNDCPT_TX_EXTENSIONS.

Usage Notes

AR_DEPOSIT_API_PUB is typically invoked from custom PL/SQL programs, concurrent program wrappers, or third-party integrations that need to create deposits in Receivables. It is not normally called interactively from a standard Oracle Forms screen; the forms-based deposit workflow uses its own underlying logic. Because it is a PUB API under the APPS schema, custom code should call it through the APPS synonym and honor the FND_API return status and message stack rather than inspecting the tables directly. Callers should commit after a successful call and use SET_PROFILE_FOR_TESTING only in non-production environments.