Search Results hours_reporting_name

Overview

APPS.PAY_MX_HOURLY_EARNINGS_V is an Oracle E-Business Suite internal view owned by the APPS schema, registered under FND Design Data as PAY.PAY_MX_HOURLY_EARNINGS_V. It is a Mexico (MX) legislative localization object whose purpose is to present, on a single row, the earnings and hours balance information associated with an assignment's payroll action for a defined period. The view joins payroll action context (assignment, tax unit, payroll action, action status and type, dates paid and earned, business group and run type) to the run and year-to-date values of a selected earnings balance and a corresponding hours balance.

Its principal role is to support Oracle payroll processes and statutory reporting for Mexican payroll, notably hourly earnings reporting where both a monetary balance and a time (hours) balance must be reported side by side. The view carries the explicit Oracle restriction: "Oracle Internal Use Only — Oracle Corporation does not support access to Oracle applications data using this object, except from standard Oracle Applications programs." Customers and integrators may query it for diagnostics or custom reporting, but it is not a supported public interface and its definition may change without notice between releases such as 12.1.1 and 12.2.2.

Underlying Base Objects

The view is defined over synonyms and packaged PL/SQL rather than raw tables. The documented dependencies are:

• PAY_ASSIGNMENT_ACTIONS — supplies the assignment action, action status and action type context.
• PAY_PAYROLL_ACTIONS — supplies payroll action and run type information.
• PAY_RUN_BALANCES — provides the run and year-to-date balance values for the assignment action.
• PAY_BALANCE_TYPES, PAY_BALANCE_ATTRIBUTES, PAY_BAL_ATTRIBUTE_DEFINITIONS — resolve balance type identifiers, names, reporting names and units of measure.
• PAY_DEFINED_BALANCES — identifies the defined balances selected for earnings and hours.
• PAY_AC_UTILITY and PAY_MX_UTILITY — packaged utility code invoked by the view, the latter providing Mexico-specific logic.

The view is not referenced by any other database object, confirming its role as a terminal reporting/read-only construct.

Key Columns

• ASSIGNMENT_ID, ASSIGNMENT_ACTION_ID, PAYROLL_ACTION_ID, BUSINESS_GROUP_ID, RUN_TYPE_ID — identification and context keys linking the row to the assignment, its action, the payroll action, the business group and the run type.
• ACTION_STATUS, ACTION_TYPE, DATE_PAID, DATE_EARNED — processing status and type of the action, with the paid and earned dates used for period selection.
• TAX_UNIT_ID — the tax unit associated with the assignment action.
• EARN_BAL_TYPE_ID, EARN_BAL_NAME, EARN_REPORTING_NAME, EARN_BAL_UOM — identifier, internal name, reporting name and unit of measure for the earnings balance.
• HOURS_BAL_TYPE_ID, HOURS_BAL_NAME, HOURS_REPORTING_NAME — the equivalent attributes for the hours balance. HOURS_BAL_NAME is the column most frequently targeted by ad hoc searches on this view.
• EARN_RUN_VAL, EARN_YTD_VAL — earnings balance value for the run and year-to-date respectively.
• HOURS_RUN_VAL, HOURS_YTD_VAL — hours balance value for the run and year-to-date respectively.

Common Use Cases and Queries

Typical uses include validating that hourly earnings have been written with a matching hours balance, reconciling run versus YTD values for a payroll period, and extracting Mexico hourly earnings data for statutory or internal reporting.

Selecting the hours balance name and its values for a given assignment action:

• SELECT assignment_id, hours_bal_name, hours_run_val, hours_ytd_val FROM apps.pay_mx_hourly_earnings_v WHERE assignment_action_id = :p_action_id;

Reconciling earnings against hours for a date range:

• SELECT assignment_id, date_earned, earn_bal_name, earn_run_val, hours_bal_name, hours_run_val FROM apps.pay_mx_hourly_earnings_v WHERE date_earned BETWEEN :p_start AND :p_end AND business_group_id = :p_bg_id ORDER BY assignment_id, date_earned;

Because the view is internal and unsupported, any query should be validated against the current release, and production integrations should prefer supported payroll balance extraction methods where available.