Search Results get_format_mask

Overview

FND_CURRENCY is a public PL/SQL package owned by the APPS schema and classified as a general-purpose utility (API classification: OTHER) rather than a formal business API. Its role within Oracle E-Business Suite 12.1.1 and 12.2.2 is to centralize the derivation of currency formatting information and precision attributes so that forms, reports, and custom code behave consistently when displaying or accepting monetary values. Rather than hard-coding decimal placement or symbol placement logic in each individual form item or report field, developers call FND_CURRENCY to obtain a format mask and precision values reflecting the settings configured for a given currency code in the FND_CURRENCIES table. Because currency precision and extended precision requirements vary by currency (for example, currencies permitting more than two decimal positions for specialized accounting scenarios), the package provides the authoritative single point of resolution for these attributes. The package is declared AUTHID CURRENT_USER, meaning it executes with the privileges of the invoking user rather than the definer, which is significant for environments where currency data visibility may be restricted.

Key Procedures and Functions

The package exposes the following documented functions and procedures.

• GET_FORMAT_MASK — Returns a currency format mask string for a specified currency code and field length, appropriate for use with the Forms SET_ITEM_PROPERTY built-in (FORMAT_MASK property) or with PL/SQL TO_CHAR conversions. It carries a WNDS pragma restriction, making it fast but limiting its permissible call contexts.
• SAFE_GET_FORMAT_MASK — A functionally equivalent but slower variant of GET_FORMAT_MASK. It is intended for situations where the WNPS restrictions of the standard function prohibit use, such as within views or WHERE clauses. The documentation notes it runs at roughly half the speed because it relies on non-caching profile functions for defaulting.
• GET_INFO — Returns precision metadata for a currency code, supplying the standard precision (digits to the right of the decimal), the extended precision to apply when greater accuracy is required, and the minimum accounting unit by which an amount may vary. It derives this information from the cached currency data sourced from the FND database table.
• BUILD_FORMAT_MASK — Constructs a currency format mask intended for use with the Forms SET_ITEM_PROPERTY built-in when assigning the FORMAT_MASK property at runtime.
• SAFE_BUILD_FORMAT_MASK — The non-caching counterpart to BUILD_FORMAT_MASK, provided for contexts where the standard version's pragma restrictions prevent invocation.

Tables Accessed

The package references FND_CURRENCIES via an APPS synonym. This table is the source of the currency definitions — precision, extended precision, and minimum accounting unit — that drive GET_INFO and, transitively, the format mask functions. FND_CURRENCY reads this data into an internal cache to accelerate repeated calls, which explains the performance distinction between the standard and SAFE variants: the standard functions rely on the cached values, while the SAFE versions fall back to slower, non-caching profile lookups that avoid the WNPS purity restriction.

Usage Notes

FND_CURRENCY is most commonly invoked from Oracle Forms when a block or item must be initialized with a currency-specific format mask, and from PL/SQL-based concurrent programs and reports that format monetary output. It is also widely reused in custom extensions: the ETRM metadata records that the package is referenced by 352 other packages, indicating it is a foundational dependency across many Oracle EBS modules. Developers should select GET_FORMAT_MASK or BUILD_FORMAT_MASK whenever the calling context permits WNDS-restricted functions, and switch to the SAFE_ prefixed variants only when the call site — such as a view definition or a WHERE clause — cannot tolerate the purity restrictions. Because precision attributes differ across currencies, calling parties should always pass the actual transactional currency code rather than assuming two-decimal formatting.