Search Results get_available_disc_on_inv
Overview
ARP_DISCOUNTS_API is a public PL/SQL API owned by the APPS schema in Oracle E-Business Suite Receivables. It encapsulates the business logic that determines the earned and maximum early-payment discounts applicable to a receipt or invoice payment schedule. Early-payment discounting in Receivables is driven by the payment terms assigned to a transaction, the discount date derived from those terms, grace-day tolerances defined on the customer profile, and the amount being applied at any given moment. Rather than forcing callers to replicate this calculation, the package exposes a controlled interface that evaluates each of these inputs and returns the resulting discount figures. It is classified as an API in the ETRM documentation for 12.2.2, meaning it is intended for programmatic invocation rather than as an internal implementation detail. The package is declared with AUTHID CURRENT_USER and is referenced by three other packages, confirming its role as a shared utility within the Receivables discount calculation layer.
Key Procedures and Functions
The package documents three callable units:
- GET_DISCOUNT — Calculates the discount that is actually available for a specified payment schedule on a given apply date, taking into account the amount being applied and whether grace days are to be honoured. It returns the discount amount together with the remaining receipt amount and the remaining invoice amount after the application. This is the fullest form of the calculation and supports callers that must update both sides of the application.
- GET_MAX_DISCOUNT — Returns the maximum discount obtainable against a payment schedule on the apply date, together with the applied amount that would be required to earn it. It is used when a caller needs to know the ceiling of the discount rather than the discount for a specific applied figure, for example when populating a default or validating a user entry.
- GET_AVAILABLE_DISC_ON_INV — A function returning a NUMBER that reports the discount available on an invoice payment schedule identified by its applied payment schedule identifier, evaluated at a specified apply date and, optionally, for a specified amount to be applied. This is the unit associated with the search term
get_available_disc_on_inv. Because the amount parameter is optional, the function can be used both to probe the discount for a prospective application and to obtain the discount available for an existing one.
Parameter lists are deliberately not reproduced here; callers should obtain the exact signatures from the package specification shipped in the AR product directory.
Tables Accessed
The package resolves its data through APPS synonyms over the following tables:
- AR_PAYMENT_SCHEDULES — The primary source. It holds the payment schedule rows for invoices and receipts, including due dates, terms, amounts, and the discount-related columns used to derive eligibility.
- RA_TERMS — Supplies the payment terms definition, including the discount percentage and the number of days within which payment must be made to earn the discount.
- RA_CUST_TRX_TYPES — Identifies the transaction type of the invoice, which influences whether and how discounting applies.
- HZ_CUSTOMER_PROFILES — Provides customer-level attributes, notably the grace-day setting that extends the discount period beyond the nominal discount date.
Usage Notes
ARP_DISCOUNTS_API is typically invoked from Receivables forms and from other Receivables packages during receipt application, where the discount available on an invoice must be computed before the application amount is finalised. It is equally usable from concurrent programs that recalculate or report on discounts, and from custom PL/SQL that automates receipt application or cash forecasting. Callers should pass the correct apply date, since the discount outcome is date-sensitive, and should set the grace days flag consistently with the customer profile if grace-day treatment is required. Because the package is an API with cross-package dependents, direct modification is unsupported; extensions should wrap the documented entry points.