Search Results get_closest_rate

Overview

GMF_GLCOMMON_DB is an Oracle EBS database package owned by the APPS schema and classified under the "OTHER" API category. In the context of Oracle E-Business Suite 12.1.1 and 12.2.2, this package serves as a central utility for currency conversion and exchange rate resolution within the Process Manufacturing (GMF) financial integration layer. Its core business purpose is to determine the appropriate exchange rate to apply when converting amounts between currencies for a specified effective date, and to advise calling modules whether a given currency pair is governed by a fixed (pegged) rate rather than a floating market rate.

The package encapsulates the rules for locating the "closest" valid exchange rate relative to a user-supplied date, returning both the numeric rate and a multiply/divide sign indicator so the caller knows whether to multiply or divide when performing the conversion. This distinction is critical in multi-currency accounting, where a rate may be quoted directly or inversely for a currency pair. The package header carries a 2002 revision marker, indicating that it is a long-standing and stable component of the Process Manufacturing currency framework.

Key Procedures and Functions

The package exposes five documented program units. The user search term "is_fixed_rate" corresponds to the core fixed-rate determination logic provided in two parallel forms.

• PROC_GET_CLOSEST_RATE — A procedure that resolves the exchange rate closest to a given date for a from/to currency combination and an optional rate type, returning the rate and a multiply/divide sign through OUT parameters, along with an error status.
• GET_CLOSEST_RATE — A function variant of the same operation that returns the exchange rate as its return value while still supplying the multiply/divide sign and error status through OUT parameters. This form is convenient for inline use in PL/SQL expressions.
• PROC_IS_FIXED_RATE — A procedure that evaluates whether the currency pair is fixed for the supplied effective date, returning a fixed-check indicator through an OUT parameter plus error status.
• IS_FIXED_RATE — The function counterpart to the above, returning a VARCHAR2 flag that indicates whether the currency pair is fixed as of the effective date, with error status returned through an OUT parameter.
• GET_INFO — A procedure that retrieves currency-related attributes for a given currency and effective date, passing back exchange rate, minimum accounting unit (MAU), and currency type through IN OUT parameters.

The package also declares two named exceptions, NO_RATE and INVALID_CURRENCY, allowing callers to handle the specific failure conditions of missing rates and unrecognized currency codes.

Tables Accessed

The package reads from two core General Ledger currency tables, accessed through APPS synonyms:

• GL_CURR_MST — The currency master table, which holds currency definitions and attributes. It is consulted to validate currency codes and to supply currency type and MAU information returned by GET_INFO, and it underpins the fixed-rate determination logic.
• GL_XCHG_RTE — The exchange rate table, which stores dated conversion rates by rate type. It is queried to locate the closest applicable rate relative to the requested effective date and rate type.

Usage Notes

GMF_GLCOMMON_DB is typically invoked by Process Manufacturing financial and cost modules, Oracle Forms-based currency entry screens, and custom PL/SQL that must convert or validate currency amounts. Because the package is classified as OTHER rather than a public API, it is generally treated as an internal utility; nevertheless, its procedures and functions are callable by any schema granted EXECUTE on the APPS package. Developers should note that the fixed-rate check (IS_FIXED_RATE and PROC_IS_FIXED_RATE) is the documented entry point for answering the "is_fixed_rate" query — determining whether a currency pair is pegged on a given date — while GET_CLOSEST_RATE and GET_INFO support the actual rate retrieval and currency attribute lookups. Callers must pass a populated error_status variable to detect the NO_RATE and INVALID_CURRENCY conditions. Per the documented metadata, no other packages reference this package, so its consumers are forms, concurrent programs, and custom code rather than dependent database APIs.