Search Results igw_report_budget




Overview
Explore in AI Chat

Overview

The IGW_REPORT_BUDGET table stores information about direct costs allocated to individual proposal budget periods within the Oracle E-Business Suite Grants Proposal module. It belongs to the IGW schema, which supports the Oracle Grants/Proposal (IGW) product family, and its documented description is "Information on direct costs for proposal budget periods." This places the object at the intersection of proposal versioning, budget periodization, and cost categorization — the reporting backbone for how a sponsor-facing proposal budget is decomposed over time and cost type.

The ETRM metadata flags this table under the IGW – Grants Proposal (Obsolete) product designation, and the DBA Data block explicitly states "Not implemented in this database." This is significant: in Oracle EBS 12.1.1 and 12.2.2, the object may exist as a documented data model artifact or a legacy/historical table from earlier Grants releases, but it is not expected to be instantiated in standard installations. Consultants should confirm existence via ALL_TABLES before writing dependent SQL.

The heuristic Data Vault classification mined from the FK structure is standalone. This suggests that in a Data Vault modeling exercise, IGW_REPORT_BUDGET would be treated as an independent entity rather than as a link or satellite, since no foreign-key parents are documented. Its composite primary key nonetheless encodes several business relationships (proposal, version, period, category), so a modeling exercise could alternatively consider separating those as hubs with a connecting link.

Key Information Stored

The table contains nine documented columns. The primary key IGW_REPORT_BUDGET_PK is composite and comprises BUDGET_PERIOD_ID, PROPOSAL_FORM_NUMBER, VERSION_ID, PROPOSAL_ID, and PROPOSAL_BUDGET_CATEGORY_CODE. A unique index, IGW_REPORT_BUDGET_U1, duplicates the same column set in a different order (PROPOSAL_ID, VERSION_ID, BUDGET_PERIOD_ID, PROPOSAL_BUDGET_CATEGORY_CODE, PROPOSAL_FORM_NUMBER), confirming that the composite is also the business-key candidate.

  • PROPOSAL_ID — identifies the parent proposal record.
  • VERSION_ID — distinguishes proposal versions, critical for historical comparison.
  • BUDGET_PERIOD_ID — the budget period (e.g., Year 1, Year 2) to which costs are attributed.
  • PROPOSAL_BUDGET_CATEGORY_CODE — the coded budget category (e.g., personnel, equipment).
  • PROPOSAL_BUDGET_CATEGORY — the descriptive/display name of the budget category.
  • PROPOSAL_FORM_NUMBER — associates the row with a specific proposal form (sponsor form structure).
  • PERIOD_TOTAL_DIRECT_COST — the aggregated direct cost for the period/category combination.
  • EB_TOTAL — a total (based on the "EB_" prefix, likely an employer burden or extended budget total) used in rollup calculations.
  • RECENTLY_UPDATED_FLAG — a status indicator used for incremental extract/reporting routines.

Common Use Cases and Queries

Typical scenarios include building period-by-period direct cost summaries for sponsor budget justification documents, comparing versions of the same proposal, and extracting incremental changes since the last report run.

SELECT PROPOSAL_ID, VERSION_ID, BUDGET_PERIOD_ID,
       PROPOSAL_BUDGET_CATEGORY, SUM(PERIOD_TOTAL_DIRECT_COST)
FROM   IGW_REPORT_BUDGET
WHERE  PROPOSAL_ID = :p_proposal_id
GROUP  BY PROPOSAL_ID, VERSION_ID, BUDGET_PERIOD_ID, PROPOSAL_BUDGET_CATEGORY;

Version comparison uses VERSION_ID in the filter to isolate the "as-submitted" versus "revised" budget. Incremental extracts filter on RECENTLY_UPDATED_FLAG = 'Y'. Because the table is obsolete and possibly unimplemented, queries should be guarded with a metadata existence check against ALL_TABLES before execution in 12.1.1 / 12.2.2 environments.

Related Objects

No foreign-key relationships are documented, so related objects are inferred from the shared business columns (PROPOSAL_ID, VERSION_ID, BUDGET_PERIOD_ID). Significant companions in the IGW Grants Proposal schema include:

Because the object is obsolete, custom reporting should prefer supported Grants Proposal views or BI Publisher data models rather than direct dependence on this table.