Search Results get_default_rate
Overview
APPS.PO_CURRENCY_SV is a server-side currency utility package within the Oracle Purchasing (PO) module of Oracle E-Business Suite, present in both 12.1.1 and 12.2.2. Its principal business function is to centralize currency validation and exchange-rate lookup logic used throughout Purchasing and its dependent modules. The package encapsulates the retrieval of daily conversion rates from the Oracle General Ledger rate tables, applies Purchasing-specific business rules for presenting inverse rates, and validates that a given currency remains active and usable within the application. Because Purchasing documents—requisitions, purchase orders, RFQs, quotations, and receipts—frequently require conversion between transaction currency and functional currency, the package provides a consistent, reusable API surface rather than duplicating rate retrieval logic in each form or concurrent program.
The package is classified as OTHER in the ETRM metadata, indicating it is not a formally published public API in the traditional sense, but it remains referenced by fifteen other packages across the application. It is a "SV" (server validation/utility) package, a naming convention common in EBS indicating internal use by sibling packages rather than direct customer extension.
Key Procedures and Functions
- VAL_CURRENCY — Validates whether a supplied currency code is still valid and enabled for use. Returns a Boolean result and is the standard gatekeeper invoked before a currency is accepted into a Purchasing transaction.
- GET_RATE — The package's central routine and the one most commonly associated with the "get_rate" search term. It retrieves the display rate and conversion rate for a given set of books, currency, rate type, and rate date. The inverse rate is returned according to client-side business rules governed by an inverse-rate display flag, meaning the caller can request either the direct or reciprocal rate presentation.
- GET_FUNCTIONAL_CURRENCY_CODE — Returns the functional currency code for the specified ledger or set of books context, allowing callers to determine the target currency for conversion.
- RATE_EXISTS — Checks whether a usable conversion rate exists for the supplied currency, rate type, and date combination, enabling callers to anticipate and handle missing-rate conditions before conversion is attempted.
- GET_CURRENCY_PRECISION — Returns the precision (number of decimal places) associated with a currency, supporting consistent rounding of monetary amounts.
- GET_CROSS_OU_RATE — Resolves conversion rates across operating units, addressing inter-operating-unit transactions where the rate path may differ from a simple ledger-level lookup.
- GET_CONVERTED_UNIT_PRICE — Computes and returns a converted unit price, typically applying the retrieved rate to a unit price value for Purchasing pricing and comparison purposes.
Tables Accessed
- FND_CURRENCIES — Provides currency definitions, enablement status, and precision attributes used by VAL_CURRENCY and GET_CURRENCY_PRECISION.
- GL_DAILY_CONVERSION_TYPES — Supplies the defined rate types (for example, corporate, spot, user-defined) that govern which rate is retrieved.
- GL_DAILY_CONVERSION_RATES — The primary source of conversion rate values; GET_RATE reads from this table as documented in the package header.
- FINANCIALS_SYSTEM_PARAMS_ALL — Supplies system-level financial configuration, including ledger and functional currency context.
- PO_SYSTEM_PARAMETERS_ALL — Supplies Purchasing-specific system parameters that influence rate handling and defaulting behavior.
Usage Notes
PO_CURRENCY_SV is normally invoked indirectly. Purchasing forms and their underlying libraries call GET_RATE and its siblings during transaction entry and validation, particularly when a user enters or changes currency, rate type, or rate date fields. Concurrent programs that process requisitions, purchase orders, or receipts rely on the same routines to perform consistent conversions during batch operations. Because fifteen other packages reference PO_CURRENCY_SV, custom extensions in the Purchasing space frequently call it as established practice.
Developers should note that the package is not a formally public API; signature changes between releases are possible and callers should be re-validated during upgrades. When integrating custom code, the inverse-rate display flag deserves particular attention, as it determines whether the caller receives the direct or reciprocal rate—an error here propagates incorrect values into pricing calculations. Rate availability should always be confirmed via RATE_EXISTS before GET_RATE is relied upon in unattended batch processing.
-
PACKAGE: APPS.PO_CURRENCY_SV
12.1.1
-
PACKAGE: APPS.PO_CURRENCY_SV
12.2.2
-
PACKAGE: APPS.ZX_TAX_RECOVERY_PKG
12.1.1
-
PACKAGE: APPS.ZX_TAX_RECOVERY_PKG
12.2.2
-
PACKAGE: APPS.GL_MC_CURRENCY_PKG
12.2.2
-
PACKAGE: APPS.GL_MC_CURRENCY_PKG
12.1.1
-
PACKAGE BODY: APPS.ZX_TAX_RECOVERY_PKG
12.1.1
-
PACKAGE BODY: APPS.ZX_TAX_RECOVERY_PKG
12.2.2
-
PACKAGE BODY: APPS.GL_MC_CURRENCY_PKG
12.1.1
-
PACKAGE BODY: APPS.GL_MC_CURRENCY_PKG
12.2.2
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on GL_CODE_COMBINATIONS
12.2.2
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on AP_TAX_CODES_ALL
12.2.2
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on AP_TAX_CODES_ALL
12.1.1
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on GL_CODE_COMBINATIONS
12.1.1
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on AP_TAX_CODES_ALL
12.1.1
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on AP_TAX_CODES_ALL
12.2.2
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on GL_CODE_COMBINATIONS
12.2.2
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on GL_CODE_COMBINATIONS
12.1.1
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on PO_VENDORS
12.1.1
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on PO_VENDORS
12.2.2
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on PO_VENDORS
12.2.2
-
APPS.ZX_TAX_RECOVERY_PKG dependencies on PO_VENDORS
12.1.1