Results for “psa_efc_summary_budgets”

34 results




Overview
Explore in AI Chat

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PSA_EFC_SUMMARY_BUDGETS is a table owned by the PSA schema within the Oracle E-Business Suite Public Sector Financials (PSA) product. Its documented purpose is to store Summary Budgets with Enhanced Funds Check. In practice, this table acts as a control or template-level association between a budget template definition and a deployed funding budget version, allowing the Enhanced Funds Check (EFC) engine to reference pre-aggregated budget balances rather than recomputing them from detail transactions on every request. This improves performance of funds availability validation in high-volume public sector budgeting and commitment control scenarios.

The table is documented in ETRM 12.2.2 with seven columns. Its heuristic Data Vault classification, as mined from the foreign key structure, is standalone. In Data Vault modeling terms, this suggests the object behaves neither as a classic hub nor a link nor a satellite, but rather as a control, configuration, or mapping table that is referenced by other processes rather than serving as a transactional integration point. This classification should be treated as a modeling suggestion rather than a strict architectural rule.

Key Information Stored

The table contains only seven documented columns, which strongly indicates a narrow, control-purpose design. The most important columns are:

  • TEMPLATE_ID — Identifies the budget template associated with the summarization logic. This is the anchor to the template definition used by EFC processing.
  • FUNDING_BUDGET_VERSION_ID — Identifies the specific funding budget version whose summary budgets are represented. This is the column most commonly used as a filter in reporting and troubleshooting queries.
  • CREATION_DATE, CREATED_BY — Standard WHO-column audit attributes recording when and by which user the summary budget row was created.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — Standard audit attributes recording the most recent modification and the session that performed it.

The surrogate-style primary key is implemented as PSA_EFC_SUMMARY_BUDGETS_PK over the composite of (TEMPLATE_ID, FUNDING_BUDGET_VERSION_ID). A unique index, PSA_EFC_SUMMARY_BUDGETS_U1, also exists over the identical column pair, confirming that this combination is the true business key. No dependent FK relationships are documented, consistent with the standalone classification.

Common Use Cases and Queries

Typical scenarios involve verifying which funding budget versions have EFC summary records generated against a given template, and diagnosing funds check failures where a summary row is missing or stale.

  • Coverage report: list all budget versions summarized for a template.
  • Funding validation lookup: confirm that a specific funding budget version is represented before running enhanced funds check.
  • Audit/compliance: report who created or last modified summary records within a period.

A representative query using the searched column:

SELECT template_id, funding_budget_version_id, creation_date, created_by
FROM psa.psa_efc_summary_budgets
WHERE funding_budget_version_id = :p_version_id;

Reporting can also join to budget version and template definition tables on the corresponding IDs to present descriptive names alongside the summary records.

Related Objects

Because the table is documented as standalone, no FK constraints are asserted in the metadata. Nonetheless, its two business-key columns imply logical references to the following object families:

  • FUNDING_BUDGET_VERSIONS — joined on FUNDING_BUDGET_VERSION_ID to resolve the version name and status.
  • Budget template definition tables (e.g., template header/detail objects in the PSA budget schema) — joined on TEMPLATE_ID.
  • PSA Enhanced Funds Check engine tables and APIs that consume summary budgets during funds availability validation.
  • Funds Check results and exceptions tables that record outcomes derived from these summaries.

Because relationships are logical rather than enforced, joins should be validated against the specific patch level of the 12.1.1 or 12.2.2 environment in use.