Search Results is_user_rate_type_allowed

Overview

PA_MULTI_CURRENCY is a public PL/SQL package owned by APPS that centralizes multi-currency handling for the Oracle Projects suite. Its declared purpose is to supply conversion services — resolving the currency, rate type, and rate date configuration that applies to a user's responsibility, and applying that configuration when amounts must be converted between currencies. The package is an AUTHID CURRENT_USER program and was historically accompanied by a commented-out pragma RESTRICT_REFERENCES(pa_multi_currency,WNDS,WNPS) directive, indicating that the original design intent was limited to read-only, non-database-state-modifying operations.

Configuration is sourced from PA_IMPLEMENTATIONS, which stores the implementation-level defaults for accounting currency, conversion rate type, and rate date code. The package also exposes a set of package global variables — G_accounting_currency_code, G_rate_date_code, and G_rate_type — together with the exceptions no_rate and invalid_currency, giving callers a shared state and a consistent error vocabulary for currency failures.

Key Procedures and Functions

• CHECK_RATE_DATE_CODE — Returns the default rate date code from PA_IMPLEMENTATIONS.
• GET_RATE_TYPE — Returns the default conversion rate type defined at the implementation level.
• GET_ACCT_CURRENCY_CODE — Returns the accounting currency code derived from the set of books associated with the user's responsibility.
• IS_USER_RATE_TYPE_ALLOWED — Determines whether a given user rate type is permitted for the current responsibility.
• CONVERT_AMOUNT — Performs a single currency conversion using the established rate type and date context.
• CONVERT_AMOUNT_SQL — Provides a SQL-callable form of conversion, suitable for embedding in queries rather than PL/SQL blocks.
• CONVERT_CLOSEST_AMOUNT — Converts an amount using the closest available rate when no exact rate exists for the requested date or type.
• FORMAT_AMOUNT — Applies currency-specific formatting rules to a numeric amount.
• VALIDATE_RATE_TYPE — Validates a supplied rate type against the implementation configuration.
• VALIDATE_CURRENCY_CODE — Validates a supplied currency code.
• INIT — Initializes package global state, populating the accounting currency, rate type, and rate date code globals.
• GET_CONVERSION_TYPE — Returns the effective conversion type for the current context.
• GET_USER_CONVERSION_TYPE — Returns the conversion type applicable to the user, resolving user-level preference or responsibility-level configuration. This is the function most frequently referenced by callers seeking the search term get_user_conversion_type.

Tables Accessed

• PA_IMPLEMENTATIONS — The primary configuration source. The package reads default_rate_date_code and default rate type values from this table, and the GET_ACCT_CURRENCY_CODE function resolves accounting currency through the responsibility's set of books.
• FND_CURRENCIES — Referenced by VALIDATE_CURRENCY_CODE and FORMAT_AMOUNT to confirm currency validity and to obtain formatting and precision attributes.
• DUAL — Used for single-row evaluations and for the SQL-callable conversion path.
• PLITBLM — The standard Oracle Projects PL/SQL index-by table of numbers, used to carry numeric arrays through the conversion routines.

Usage Notes

PA_MULTI_CURRENCY is a utility layer rather than a transactional API. It is invoked by Oracle Projects forms and concurrent programs whenever amounts must be displayed, reported, or converted in a currency other than the entered currency, and it is referenced by 85 other packages within the EBS schema — a clear indicator of its role as shared infrastructure.

Custom code should not call the conversion functions without first ensuring that package globals are populated through INIT, or that the configuration-dependent functions are used to obtain the rate type and rate date code explicitly. Because the package is AUTHID CURRENT_USER and the historic purity pragmas were commented out in this source line, callers should treat the conversion functions as read-only in intent but verify purity requirements independently before relying on them inside SQL statements. Direct DML against PA_IMPLEMENTATIONS or FND_CURRENCIES is not appropriate; configuration changes belong in the standard implementation and currency setup paths.