Search Results pay_gcc_curr_conv




Overview

PAY_GCC_CURR_CONV is a PL/SQL package owned by the APPS schema in Oracle E-Business Suite. Its header comment (pygcccur.pkh) indicates it belongs to the Oracle Payroll (PAY) product family and that the source was last revised in early 2013, coinciding with GCC localization maintenance for the 12.2 release cycle. The package is classified as OTHER in the ETRM metadata rather than as a formal public API, which means Oracle does not guarantee backward compatibility of its signature across patches.

The name and the single exposed function indicate the package's purpose: resolving the appropriate currency conversion mechanism for a payroll run when the payroll business group operates under GCC legislative requirements. GCC localization places specific obligations on currency handling, particularly where a statutory currency differs from the ledger currency or where the conversion rate must be tied to the date on which earnings were actually earned rather than the date on which the payroll process runs. The package encapsulates that decision logic so that payroll processing, prepayments, and third-party payment flows resolve conversion information consistently.

Key Procedures and Functions

  • GET_CONVERSION_TYPE — The sole documented program unit. It accepts inputs including the business group identifier, the date the earnings were earned, a processing type discriminator, and returns the conversion type to be applied. It also exposes an OUT parameter that returns the effective conversion date, allowing the caller to retain and reuse the resolved date instead of recalculating it. The return value corresponds to a conversion type name recognized by the general ledger, permitting the payroll engine to select the correct rate source without hard-coding rates or rate types in the calling code. The AUTHID CURRENT_USER declaration means the function executes with the privileges of the invoking session, so callers must have the necessary grants on the underlying data.

No additional procedures or functions are documented in the ETRM record for this package, and it is referenced by zero other packages, indicating it is a leaf-level utility rather than a shared framework component.

Tables Accessed

  • GL_DAILY_CONVERSION_TYPES — The general ledger lookup that defines the conversion type names available to the application. GET_CONVERSION_TYPE reads this table to validate and resolve the conversion type it returns, ensuring the value corresponds to an enabled, meaningful rate type rather than an arbitrary string.
  • PAY_USER_COLUMN_INSTANCES_F — The payroll user-defined column instance table. This is the route by which a business group's configuration is inspected, since user column instances hold the legislative and business-group-specific definitions that determine which rates apply. Reading this table allows the function to tailor its result to the business group supplied by the caller.

Both tables are accessed through APPS synonyms, consistent with standard EBS coding practice and with the AUTHID CURRENT_USER setting.

Usage Notes

Because the package is not registered as a public API and is referenced by no other package in the ETRM inventory, it is best understood as internal payroll infrastructure. In practice it is invoked from Oracle Payroll localization code and from GCC-specific formula or fast-formula contexts, where a payroll calculation must determine which conversion type and conversion date apply before retrieving a rate. Typical call sites include payroll run processing, prepayment generation, and any custom code extending GCC payroll that needs to mirror Oracle's own conversion selection rather than inventing its own logic.

Developers using this package should treat the signature as subject to change across patch sets. When calling GET_CONVERSION_TYPE, the business group identifier and the date earned should be derived from the payroll context in which the call occurs, and the OUT conversion date should be honored by the caller to guarantee that the rate applied matches the date Oracle selected. Direct DML against the underlying tables is neither required nor advisable; the package should be invoked as-is within the same session and privilege context as the calling payroll code.