Search Results fis_cycq_start

Overview

FII_TIME_WH_API is an Oracle EBS Applications (APPS) PL/SQL package that belongs to the Enterprise Tax, Regulatory, and Reporting (ETRM / FII) family of utilities. Its business function is to supply consistent, calendar-aware date resolution services to downstream ETRM components. Specifically, the package answers questions about where the current reporting period falls relative to fiscal and enterprise calendars: the start and end of the current quarter, the current year, the previous year, and equivalent periods in prior years. Fiscal reporting, statutory submissions, and time-intelligence reporting in ETRM all require uniform definitions of period boundaries; centralizing that logic in a single API prevents divergent date calculations across forms, concurrent programs, and reporting code. The package is classified in ETRM as an API and is referenced by 26 other packages, confirming its role as a foundational dependency rather than an end-user-facing component. The header comment ($Header: FIIQTRSS.pls 120.0 2002/08/24) indicates the package originates from the FII (Financial Intelligence) quarter-related source module and has been stable since its initial release.

Key Procedures and Functions

The documented interface exposes 25 procedures and functions. The enterprise-calendar functions return the boundaries of periods defined by the enterprise calendar: ENT_CYCQ_START and ENT_CYCQ_END return the start and end of the current year, current quarter; ENT_LYCQ_START and ENT_LYCQ_END return the same boundaries for the equivalent quarter of the prior year; ENT_CY_START and ENT_CY_END and ENT_LY_START and ENT_LY_END extend this to full current-year and last-year boundaries; ENT_LYCQ_TODAY1 and ENT_LYCQ_TODAY2 return day-aligned values for the prior-year current quarter. The fiscal-calendar functions perform the analogous service for the fiscal calendar: GET_CURR_EQTR_START and GET_CURR_EQTR_END return the current fiscal quarter boundaries (the “equal quarter” used by ETRM’s fiscal time dimension), while GET_FQTR_START and GET_FQTR_END provide the more general fiscal quarter start and end. Utility functions include TODAY, TODAYTIME, and ENT_TODAY, which return the current date or date-time, and GET_CYCQ_PK_KEY and GET_CYCM_PK_KEY, which return the surrogate primary-key values identifying the current-year-current-quarter and current-year-current-month rows in the time dimension. FIS_CYCQ_START supplies a fiscal-calendar current-quarter start value. All date-returning functions raise an exception if the underlying SQL fails.

Tables Accessed

The package reads the ETRM time-dimension tables through APPS synonyms: EDW_TIME_EP_CAL_QTR_LTC (the enterprise-calendar quarter lookup used to derive enterprise quarter boundaries), EDW_TIME_M (the master time/month dimension providing the calendar hierarchy and surrogate keys), and EDW_TIME_MONTH_LTC (the month-level lookup). These tables supply the quarter, month, and year definitions from which the API derives period start and end dates and the primary-key keys returned by the PK functions. The documentation records no writes to these tables; the package is a read-only query service against the time dimension.

Usage Notes

FII_TIME_WH_API is a server-side utility API and is not intended for direct end-user invocation. It is typically called from ETRM forms, concurrent programs, and custom PL/SQL that need normalized period boundaries, for example when stamping a report with its current fiscal quarter or when selecting rows for a current-quarter extract. Several functions cache their results after initial access within a session, so repeated calls are inexpensive; callers should nonetheless avoid holding results across a session boundary where the system date may have advanced. The function GET_CURR_EQTR_START, which the user searched for, returns the current fiscal quarter start date and is the appropriate entry point when a report or validation rule must align to the ETRM fiscal quarter rather than the enterprise calendar. Because it raises an exception on SQL error, calling code should include an exception handler. Given its 26 dependent packages, changes to this API should be treated as high-impact.