Search Results check_prepay_payment_term




Overview
Explore in AI Chat

Overview

AR_PUBLIC_UTILS is a public PL/SQL utility package in the Oracle EBS Receivables (AR) module, owned by the APPS schema and declared with AUTHID CURRENT_USER. As its name implies, it exposes reusable, publicly callable routines that support Receivables payment processing, prepayment validation, and receipt-to-application retrieval. The package header carries the identifier ARXPUTLS.pls 120.4, dated 30-Oct-2005, indicating a long-stable interface maintained across the 12.1.1 and 12.2.2 releases.

The package is classified in the ETRM repository under API classification OTHER. Its primary business purpose is to centralize logic that other Receivables programs require: retrieving the full receipt and application context for a payment server order number, and evaluating whether a transaction or its payment terms qualify as a prepayment. Because these operations are consumed by multiple internal and external callers, the package is referenced by nine other packages within the E-Business Suite, confirming its role as a shared dependency rather than a standalone program.

The package also declares a public collection type, application_tbl_type, defined as a PL/SQL table of ar_receivable_applications%ROWTYPE indexed by BINARY_INTEGER. This type allows a caller to receive an entire set of application rows in a single outbound parameter, which is central to the get_payment_info interface.

Key Procedures and Functions

The ETRM metadata documents three callable units within APPS.AR_PUBLIC_UTILS.

  • GET_PAYMENT_INFO — Returns the receipt and application details associated with a given payment server order number. The routine accepts a payment server order number and an application type (valid values include APP, UNAPP, ACC, OTHER ACC, and ACTIVITY), and returns a receipt header row, a table of receivable application rows, and the standard EBS return status/message outputs. The package header history attributes its creation to S. Nambiar on 22-Jan-2002, driven by Bug 2195124, which required CRM-iPayment to obtain invoice information for a payment server order number.
  • CHECK_PREPAY_PAYMENT_TERM — Evaluates payment term information to determine whether a prepayment condition applies to a given transaction or customer setup. It is invoked when the application must decide whether payment terms designate a prepayment.
  • CHECK_PREPAY_TRANSACTION — Determines whether a specific transaction qualifies as a prepayment. This is the procedure most commonly associated with the user search term check_prepay_transaction, and it is the entry point customizations typically call before deciding how a receipt should be applied.

Tables Accessed

The package operates against five documented Receivables tables, referenced through APPS synonyms:

  • AR_CASH_RECEIPTS — Source of receipt header information, including the payment server order number used as the primary lookup key by GET_PAYMENT_INFO.
  • AR_RECEIVABLE_APPLICATIONS — Source of application rows returned through the application_tbl_type collection; defines the row structure of that type.
  • AR_CASH_RECEIPT_HISTORY — Provides receipt status and activity history used to complete the payment picture.
  • RA_CUSTOMER_TRX — Supplies transaction details required for prepayment determination by CHECK_PREPAY_TRANSACTION.
  • RA_TERMS — Supplies payment term definitions consumed by CHECK_PREPAY_PAYMENT_TERM.

Usage Notes

AR_PUBLIC_UTILS is an internal utility layer, not an end-user program. It is typically invoked from Receivables forms, concurrent programs, workflow activities, and custom PL/SQL that needs to resolve receipt or prepayment context without duplicating core logic. Because it is a PUBLIC package in the APPS schema, custom code should call it through the APPS synonym and must respect the AUTHID CURRENT_USER semantics, meaning privileges are evaluated against the calling schema.

The package is referenced by nine other packages, so changes to its signatures carry broad impact and should be treated as an interface change. When diagnosing prepayment behavior in 12.1.1 or 12.2.2, CHECK_PREPAY_TRANSACTION and CHECK_PREPAY_PAYMENT_TERM are the relevant diagnostics, while GET_PAYMENT_INFO remains the standard mechanism for retrieving receipt and application data by payment server order number, particularly in CRM-iPayment integration flows.