Search Results transaction_source_description

Overview

PAFV_EXPENDITURE_GROUPS is an APPS-owned Business Intelligence System (BIS) view in Oracle E-Business Suite, registered under FND Design Data as PA.PAFV_EXPENDITURE_GROUPS and marked VALID in both 12.1.1 and 12.2.2. The view presents information about groups or batches of user-entered, pre-approved expenditures within Oracle Projects, consolidating expenditure group headers with their associated transaction source, system linkage, and operating unit context into a single denormalized reporting surface.

The view carries the standard Oracle warning that it is for Oracle Internal Use Only and that supported access is limited to standard Oracle Applications programs. Its designation as a Business Intelligence System view indicates its intended role as a read-only reporting and integration interface rather than a transactional object. It is not referenced by any other database object, confirming that it sits at the top of the dependency chain as a presentation-layer construct. Users searching on "transaction_source_description" will find that the view surfaces this attribute directly as a column, sparing them the join to PA_TRANSACTION_SOURCES required when querying the underlying base table.

Underlying Base Objects

The view is defined over four documented base objects, all accessed through APPS synonyms:

• PA_EXPENDITURE_GROUPS_ALL — the primary transactional table holding expenditure group headers, including group name, description, ending date, control count, and control total amount.
• PA_TRANSACTION_SOURCES — supplies TRANSACTION_SOURCE and TRANSACTION_SOURCE_DESCRIPTION, resolving the source code to its user-facing description.
• PA_SYSTEM_LINKAGES — provides SYSTEM_LINKAGE_FUNCTION, which identifies the expenditure type class associated with the group.
• HR_ALL_ORGANIZATION_UNITS_TL — the translated organization table supplying ORGANIZATION_NAME for the ORG_ID of each group.

Because HR_ALL_ORGANIZATION_UNITS_TL is a translation table, ORGANIZATION_NAME is returned in the session's language, which is significant for multilingual deployments.

Key Columns

• EXPENDITURE_GROUP (VARCHAR2, 240) — the user-entered name identifying the group or batch.
• DESCRIPTION (VARCHAR2, 250) — free-text description of the expenditure group.
• TRANSACTION_SOURCE (VARCHAR2, 30) — the transaction source code, derived from PA_TRANSACTION_SOURCES.
• TRANSACTION_SOURCE_DESCRIPTION (VARCHAR2, 240) — the descriptive name of the transaction source; this is the column most commonly targeted when users search by that term.
• SYSTEM_LINKAGE_FUNCTION (VARCHAR2, 80) — the expenditure type class linked to the group.
• EXPENDITURE_ENDING_DATE (DATE) — the accounting end date for the expenditure group.
• CONTROL_COUNT (VARCHAR2, 20) and CONTROL_TOTAL_AMOUNT (NUMBER, 22) — batch control totals for reconciliation of entered expenditures.
• ORG_ID (NUMBER, 15) and ORGANIZATION_NAME (VARCHAR2, 240) — operating unit identifier and its translated name.
• _LA:STATUS (CHAR, 77) — the multi-language descriptive flexfield status attribute.
• LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY — standard WHO audit columns.

Common Use Cases and Queries

Typical scenarios include reconciling pre-approved expenditure batches by source, validating control totals against detail transactions, and building operating-unit-level reporting of expenditure group activity. The following query lists expenditure groups for a given operating unit with their transaction source descriptions and control totals:

SELECT expenditure_group,
       transaction_source,
       transaction_source_description,
       expenditure_ending_date,
       control_count,
       control_total_amount,
       organization_name
  FROM apps.pafv_expenditure_groups
 WHERE org_id = :p_org_id
   AND expenditure_ending_date BETWEEN :p_start AND :p_end
 ORDER BY expenditure_ending_date, expenditure_group;

Because the view is a BIS construct, queries should remain read-only and avoid reliance on the _LA:STATUS column in custom logic. All access is governed by the Oracle Internal Use Only restriction, so custom code referencing this view should be validated against supported Oracle Projects APIs wherever transactional behavior is required.