Search Results last_iyea_rtax_adj

Overview

PAY_KR_SEP_RESULT_NET_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, defined within the PAY (Payroll) product family. It is a Korea-localized (KR) view that exposes the result values produced by the Separation Net Pay process, keyed on the assignment_action_id generated when a payroll action is run. Because Oracle Payroll stores calculation results in the generic balance and defined-balance architecture rather than in a flat payroll table, this view acts as a semantic convenience layer: it calls packaged PL/SQL APIs to resolve named balances and defined items into discrete, report-ready columns.

The view's role is primarily reporting and integration. External reports, BI Publisher templates, extracts, and downstream interfaces can select a simple set of columns without embedding the complex balance-lookup logic each time. As with all EBS views of this class, it does not store data; every query executes the underlying function calls at run time.

Underlying Base Objects

The documented definition joins three payroll transaction objects and depends on one PL/SQL package for its column values. The FROM clause references PAY_PAYROLL_ACTIONS (aliased PPA) and PAY_ASSIGNMENT_ACTIONS (aliased PAA); the two are joined on the key relationship linking a payroll action to its constituent assignment actions. A NOT EXISTS subquery over PAY_RUN_TYPES_F, PAY_PAYROLL_ACTIONS, PAY_ASSIGNMENT_ACTIONS, and PAY_ACTION_INTERLOCKS (all present as SYNONYMs in APPS) filters out assignments whose actions are still interlocked or otherwise not finalized, ensuring only settled results are returned.

• PAY_ASSIGNMENT_ACTIONS — source of assignment_action_id and assignment_id, the grain of the view.
• PAY_PAYROLL_ACTIONS — supplies effective_date and date_earned, plus run context.
• PAY_RUN_TYPES_F — used in the exclusion logic to identify run types.
• PAY_ACTION_INTERLOCKS — used to detect and exclude locked or in-process actions.
• PAY_KR_REPORT_PKG — the package providing GET_BALANCE_VALUE and GET_DBITEM_VALUE, which resolve balance names such as TOTAL_TAXABLE_EARNINGS and NET_PAY at the _ASG_RUN, _ASG_ITD, and _ASG_YTD dimensions.

Key Columns

• ASSIGNMENT_ACTION_ID / ASSIGNMENT_ID — the primary keys used to relate the view to other payroll result queries.
• EFFECTIVE_DATE / DATE_EARNED — payroll period context taken from the payroll action.
• RUN_TYPE_ID — identifies the payroll run definition.
• TOTAL_TAXABLE_EARNINGS — taxable earnings balance accumulated at the assignment run level (_ASG_RUN); this is the column most directly relevant to searches on that term.
• ITAX, RTAX, STAX — income, resident, and special tax balances for the run.
• NET_PAY — net pay balance for the run, the principal output of the separation net pay calculation.
• NP_PREM_FUND_REIMB — national pension premium fund reimbursement at the _ASG_ITD level.
• VOL_DEDUCTIONS / INVOL_DEDUCTIONS — voluntary and involuntary deduction totals.
• LAST_IYEA_ITAX_ADJ, LAST_IYEA_RTAX_ADJ, LAST_IYEA_STAX_ADJ — prior-year tax adjustment defined items (KR_LIYEA_*).
• LAST_IHIA_PREM_EE_ADJ / LAST_IHIA_PREM_ER_ADJ — prior-year health insurance premium separation adjustments for employee and employer, resolved at _ASG_YTD.

Common Use Cases and Queries

The most frequent requirement is to report taxable earnings and net pay for a separation run, particularly when reconciling tax balances. Because TOTAL_TAXABLE_EARNINGS is exposed directly, users avoid rebuilding the balance-name string and dimension arguments in each query.

• Separation net pay reconciliation by assignment.
• Tax reporting extracts for Korean income, resident, and special tax.
• Prior-year adjustment tracking using the defined-item columns.
• Feeding downstream interfaces that require a single row per assignment action.

A representative query:

• SELECT assignment_action_id, assignment_id, effective_date, total_taxable_earnings, itax, rtax, stax, net_pay FROM apps.pay_kr_sep_result_net_v WHERE assignment_action_id = :p_action_id;

To filter by run date:

• SELECT assignment_id, total_taxable_earnings, net_pay FROM apps.pay_kr_sep_result_net_v WHERE effective_date BETWEEN :p_from AND :p_to ORDER BY effective_date;

Because columns are resolved by PL/SQL calls, queries returning many rows can be expensive; filter by assignment_action_id or date range wherever possible, and avoid unfiltered full scans in high-volume payroll runs.