Search Results get_fiscal_year

Overview

The APPS.IGC_CC_MPFS_PROCESS_PKG package belongs to the Oracle E-Business Suite Public Sector / Grants Accounting family of modules (the IGC prefix corresponds to the Oracle Grants / Contracts component). It is owned by the APPS schema and declared with AUTHID CURRENT_USER, meaning that its SQL statements execute with the privileges of the calling user rather than the definer, a common pattern for packages invoked from concurrent programs, forms, or custom code under the Applications security model. The package's header carries the revision string $Header: IGCCMPSS.pls 120.5.12020000.1 2013/02/15 ... appldev ship $, confirming it is a shipped, supported Oracle object.

The central purpose of the package is the Mass Payment Forecast Shift (MPFS) process. MPFS supports the forecasting and shifting of payment schedules for awards and contracts managed in Oracle Grants/Contracts, enabling users to project cash requirements across fiscal periods and to redistribute forecasted payments. The package encapsulates both the fiscal-calendar logic needed to determine a fiscal year from a given date and the driving entry point for the batch forecast-shift job.

Key Procedures and Functions

The ETRM metadata documents two public program units in the package specification:

• GET_FISCAL_YEAR — A function that accepts a date and a set-of-books identifier and returns a fiscal year as a number. It resolves the fiscal year that corresponds to the supplied date for the specified ledger, using the accounting calendar definitions. This is the object most directly associated with the search term "get_fiscal_year", and it is the fiscal-calendar utility underpinning the forecasting logic.
• MASS_PAYMENT_FORECAST_SHIFT_MAIN — A procedure that serves as the main driver of the Mass Payment Forecast Shift batch. Its parameters include standard concurrent-program OUT parameters (errbuf, retcode), a process phase, an owner, a start and end date, transfer and target dates, and a threshold value. It orchestrates the selection, forecasting, and shifting of payment records according to the supplied date range and thresholds.

The package also contains internal (private) helper logic supporting period determination and interface processing, but only the two units above are exposed in the specification.

Tables Accessed

The package references a mix of Oracle Grants/Contracts staging, accounting, and purchasing tables via APPS synonyms:

• Grants/Contracts transactional tables: IGC_CC_HEADERS, IGC_CC_ACCT_LINES, IGC_CC_DET_PF, IGC_CC_ACTIONS, and IGC_CC_INTERFACE hold award/contract headers, accounting lines, detail payment-forecast data, actions, and interface rows that the MPFS process reads and updates.
• Process bookkeeping: IGC_CC_PROCESS_DATA, IGC_CC_PROCESS_EXCEPTIONS, and IGC_CC_PERIODS record run parameters, log exceptions, and define Grants periods.
• General Ledger calendar tables: GL_PERIODS, GL_PERIOD_TYPES, and GL_PERIOD_STATUSES supply the fiscal calendar used by GET_FISCAL_YEAR to map a date to the correct fiscal year and period.
• Purchasing: PO_HEADERS_ALL provides purchase-order information associated with forecasted payments.
• Application registry: FND_APPLICATION is queried for application identifiers used during processing.

Usage Notes

MASS_PAYMENT_FORECAST_SHIFT_MAIN is designed to be registered and launched as an Oracle Concurrent Program, typically from the Grants/Contracts responsibility. The errbuf/retcode signature and the process-phase, owner, and date parameters are consistent with the standard concurrent-manager API. The GET_FISCAL_YEAR function is a reusable fiscal-calendar utility that may be called from custom PL/SQL, forms, or reports whenever a date must be converted to a fiscal year for a given set of books. Because the package is AUTHID CURRENT_USER, callers must possess adequate privileges on the underlying tables. The package is not referenced by other documented packages, so it operates as a self-contained process driver rather than a shared library. In EBS 12.1.1 and 12.2.2 the object resides under the APPS schema and follows the standard concurrent-program invocation pattern.