Search Results get_payment_method_default

Overview

ARP_TRX_DEFAULTS_3 is a public PL/SQL package body in the Oracle Receivables (AR) module of Oracle E-Business Suite, owned by the APPS schema. It belongs to the AR Transaction Defaults family of packages, whose purpose is to derive and cache the defaulting values used when an AR transaction or receipt is created. The package resolves remit-to addresses, payment methods, bank account defaults, payment instruments, payment channels, terms, and additional customer information that Oracle Receivables applies when a user opens a receipt or transaction form without explicitly supplying those attributes.

The body carries a version header dated 2009 and is present in both 12.1.1 and 12.2.2 installations. It is classified as "OTHER" rather than a formal public API, which indicates it is primarily an internal defaulting utility consumed by other AR packages and forms rather than by external integrations. The metadata records 15 documented procedures and functions, and it is referenced by 14 other packages, confirming its role as a shared defaulting service within the Receivables stack.

Key Procedures and Functions

The package exposes the following documented routines:

• GET_DEFAULT_REMIT_TO — returns the default remit-to address. The documentation notes that it raises NO_DATA_FOUND when no default remit-to address has been configured, and that it caches the resolved address in package-level variables.
• GET_REMIT_TO_ADDRESS and GET_REMIT_TO_DEFAULT — companion routines that resolve a specific remit-to address and the default remit-to setting respectively, supporting the caching strategy used by the primary getter.
• GET_PAYMENT_METHOD_DEFAULT — derives the default payment method for a receipt, reading from receipt method and class configuration.
• CHECK_PAYMENT_METHOD — validates or checks a payment method, the routine most relevant to the searched term "check_payment_method". It is invoked to confirm the applicability of a payment method before it is applied to a receipt.
• GET_BANK_DEFAULTS and GET_BR_BANK_DEFAULTS — return default bank and bank account attributes, including the Brazil-specific bank defaulting variant.
• GET_PAY_METHOD_AND_BANK_DEFLTS — a combined routine that resolves both the payment method and its associated bank defaults in a single call.
• GET_TERM_DEFAULT — returns the default payment term.
• GET_ADDITIONAL_CUSTOMER_INFO — retrieves supplementary customer attributes used during defaulting.
• GET_PAYMENT_CHANNEL_NAME and GET_PAYMENT_INSTRUMENT — resolve the payment channel and payment instrument defaults.
• GET_PARTY_ID — resolves the party identifier associated with the customer.
• GET_INSTR_DEFAULTS — returns instrument-level defaults.
• INIT — initializes package-level state such as the set of books, base currency code, precision, and minimum accountable unit held in global variables.

Tables Accessed

The package reads configuration and master data through APPS synonyms. Receipt configuration is drawn from AR_RECEIPT_CLASSES, AR_RECEIPT_METHODS, AR_RECEIPT_METHOD_ACCOUNTS, and AR_SYSTEM_PARAMETERS. Bank and currency data come from CE_BANK_ACCOUNTS, CE_BANK_ACCT_USES_ALL, and FND_CURRENCIES. Customer and location data are sourced from HZ_CUST_ACCOUNTS, HZ_CUST_SITE_USES, HZ_LOCATIONS, and HZ_CUSTOMER_PROFILES. Transaction and terms defaults are read from RA_CUSTOMER_TRX, RA_CUST_TRX_TYPES, and RA_TERMS. FND_APPLICATION supports application context lookups.

Usage Notes

ARP_TRX_DEFAULTS_3 is typically invoked indirectly by other AR packages, forms, and concurrent programs during receipt and transaction entry, rather than being called directly by end users. Its 14 dependent packages confirm it functions as a shared service layer. Custom code should treat it as an internal defaulting utility: rely on the documented public routines and respect the NO_DATA_FOUND behavior of GET_DEFAULT_REMIT_TO. The "check_payment_method" routine is most useful for validating a payment method against existing receipt method configuration before persisting a receipt.