Search Results feed_checking_code

Overview

The PAY_BALANCE_DIMENSIONS_VL view is a translation-enabled (VL, "view localized") database object owned by the APPS schema within the Oracle E-Business Suite Payroll (PAY) module. It exposes the definition of balance dimensions — the foundational metadata structures that determine how payroll balances are accumulated, stored, and reported for assignments, elements, and legislative contexts. Because payroll balances are the core mechanism through which Oracle Payroll tracks cumulative values such as gross earnings, tax withheld, and net pay, the definition of each balance dimension drives nearly all downstream balance calculations.

In Oracle EBS 12.1.1 and 12.2.2, this view serves as the read interface for balance dimension setup data. It combines the language-independent base definition with the translated (language-specific) name and description, ensuring that reports, concurrent programs, and integrations retrieve dimension text in the session's current language. Report developers and integration specialists query this view rather than the underlying tables to avoid duplicate language rows and to obtain user-facing descriptive text directly.

Underlying Base Objects

The view is defined over two documented base objects, both referenced through APPS synonyms:

• PAY_BALANCE_DIMENSIONS — the language-independent table holding the structural definition of each balance dimension, including identifiers, routing, checking rules, and level attributes. It is aliased as B in the view text.
• PAY_BALANCE_DIMENSIONS_TL — the translation table holding DIMENSION_NAME and DESCRIPTION in each installed language. It is aliased as TL.

The two objects are joined on BALANCE_DIMENSION_ID, with the translation side further filtered by TL.LANGUAGE = USERENV('LANG'). This predicate restricts the result set to a single language row per dimension, which is the defining characteristic of a VL view in EBS. The ROW_ID column is derived from the ROWID of the base PAY_BALANCE_DIMENSIONS row, providing a stable reference into the underlying record.

Key Columns

• BALANCE_DIMENSION_ID — primary identifier for the balance dimension; the join key across both base objects.
• DIMENSION_NAME and DESCRIPTION — translated, user-facing text sourced from the TL table.
• BUSINESS_GROUP_ID — the business group that owns the dimension, enabling multi-organization filtering.
• LEGISLATION_CODE and LEGISLATION_SUBGROUP — the legislative context in which the dimension operates.
• DIMENSION_TYPE and DIMENSION_LEVEL — classify the dimension and its aggregation level.
• ROUTE_ID — links the dimension to its routing definition governing where balances are written.
• DATABASE_ITEM_SUFFIX and DATABASE_ITEM_FUNCTION — identify the database item naming and function used when the dimension is persisted.
• FEED_CHECKING_CODE, FEED_CHECKING_TYPE, EXPIRY_CHECKING_CODE, and EXPIRY_CHECKING_LEVEL — control validation of balance feeds and expiry processing.
• PAYMENTS_FLAG, PERIOD_TYPE, START_DATE_CODE, SAVE_RUN_BALANCE_ENABLED — behavioral flags influencing payroll run accumulation and payment attributes.
• ASG_ACTION_BALANCE_DIM_ID — reference to an associated assignment-action balance dimension.

Common Use Cases and Queries

Typical uses include validating balance dimension setup, building custom balance reports, and migrating definitions between environments. A standard query filters by business group and legislation to list named dimensions:

• List all dimensions with their translated names: SELECT balance_dimension_id, dimension_name, legislation_code FROM pay_balance_dimensions_vl ORDER BY dimension_name;
• Filter by legislation and business group: SELECT dimension_name, dimension_type, dimension_level FROM pay_balance_dimensions_vl WHERE legislation_code = :leg AND business_group_id = :bg;
• Join to routing or feed metadata using ROUTE_ID or BALANCE_DIMENSION_ID to reconcile configured balance feeds.
• Resolve the underlying row reference via ROW_ID when performing DML or tracing back to PAY_BALANCE_DIMENSIONS.

Because the view enforces a single-language predicate, callers automatically receive translated text without explicit language joins, simplifying report SQL and ensuring consistent output across localized EBS deployments.