Search Results get_cross_ou_rate

Overview

PO_CURRENCY_SV is a server-side PL/SQL package owned by APPS within the Oracle E-Business Suite Purchasing module. Its name follows the "SV" (Server Validation) convention used widely across EBS, indicating that the package supplies currency-related validation, derivation, and conversion services consumed internally by the Purchasing application. In Oracle EBS 12.1.1 and 12.2.2, Purchasing must resolve functional currency, validate currency codes, confirm the existence of exchange rate definitions, and convert transactional amounts and unit prices between currencies. PO_CURRENCY_SV centralizes these operations so that forms, concurrent programs, and other PL/SQL APIs obtain consistent multi-currency behavior rather than reimplementing conversion logic individually.

The package was built with standard PO debugging instrumentation, as shown by the initialization of the PO_DEBUG flags (g_debug_stmt and g_debug_unexp) and the use of PO_MESSAGE_S.SQL_ERROR for error reporting. The excerpt identifies the package as a "Shared Proc" component, confirming it is reused across multiple Purchasing flows.

Key Procedures and Functions

• VAL_CURRENCY — Validates that a supplied currency code exists in FND_CURRENCIES and is currently enabled, checking the enabled flag against the active date range. It returns a Boolean result, following the standard EBS validation-function pattern.
• RATE_EXISTS — Determines whether an exchange rate is defined for a given currency pair, rate type, and effective date. This is the routine most often referenced when callers need to confirm that a conversion rate is available before attempting a conversion.
• GET_RATE — Retrieves the exchange rate for a specified set of books, currency, rate type, and rate date. It returns both the conversion rate and a display rate, and honors a flag controlling whether the inverse rate should be displayed.
• GET_FUNCTIONAL_CURRENCY_CODE — Returns the functional currency code associated with a set of books or operating unit, establishing the base currency for accounting entries.
• GET_CURRENCY_PRECISION — Returns the precision (number of decimal places) configured for a currency, used to round converted monetary and unit price values correctly.
• GET_CROSS_OU_RATE — Supplies a conversion rate for transactions spanning multiple operating units, a requirement largely introduced by the multi-org architecture supported in Release 12.
• GET_CONVERTED_UNIT_PRICE — Converts a unit price from one currency to another, applying the appropriate exchange rate and precision rules for purchasing documents.

The ETRM metadata lists eleven documented identifiers in total; the remaining entries correspond to the package NAME and internal declarations.

Tables Accessed

• FND_CURRENCIES — Provides currency definitions, enabled status, and active date ranges used by VAL_CURRENCY and currency-related lookups.
• GL_DAILY_CONVERSION_TYPES — Supplies the rate type definitions used when resolving exchange rates.
• FINANCIALS_SYSTEM_PARAMS_ALL — Holds financials system options, including functional currency context.
• PO_SYSTEM_PARAMETERS_ALL — Provides Purchasing system parameters that influence rate types and conversion behavior.

All access is performed through APPS synonyms. Conversion-rate values themselves are obtained via the GL_CURRENCY_API call visible in the excerpt, so this package acts as a Purchasing-oriented wrapper over the General Ledger currency API.

Usage Notes

PO_CURRENCY_SV is an internal server-side package and is not exposed as an end-user API in the same manner as a public interface such as PO_CURRENCY_API. It is principally invoked by Purchasing forms and by other PL/SQL packages during document entry and validation, most notably when a user enters or changes a currency on a requisition, purchase order, or RFQ, and when amounts and unit prices must be converted to the functional currency. The ETRM record indicates the package is referenced by fifteen other packages, confirming broad internal reuse across purchasing and related modules.

Custom code may call the package, but developers should note that its maintenance version is dated 2005 and that GL_CURRENCY_API supplies the underlying rate. Direct calls should therefore be treated as unsupported extensions, and the standard public currency APIs should be preferred where they provide equivalent functionality.