Search Results pay_assignment_actions_n51




Overview
Explore in AI Chat

Overview

APPS.PAY_JP_PRE_ITAX_V is a reporting view in Oracle E-Business Suite (EBS) 12.1.1 and 12.2.2 that consolidates Japanese income tax (itax) and year-end adjustment (YEA) deduction information at the payroll action level. Its name reflects its purpose: "JP" for Japan, "PRE" for preliminary or pre-processing, and "ITAX" for income tax. The view joins payroll action, assignment action, and Japanese pre-tax detail records to surface the salary category and itax category combinations that drive Japanese tax calculation and reporting.

The view is defined with a restrictive predicate that limits results to completed payroll and assignment actions whose action type is one of R, Q, B, or I. It further filters the underlying pre-tax records to salary categories YEA and RE_YEA and to itax categories M_KOU, M_OTSU, D_KOU, D_OTSU, and D_HEI. A NOT EXISTS subquery ensures that a future YEA assignment action does not already exist in the same tax year, preventing double-counting of year-end adjustment data. The view therefore presents the earliest qualifying YEA record per assignment, organization, and year.

Underlying Base Objects

ETRM metadata for 12.2.2 documents the following referenced base objects: FND_NUMBER (package), PAY_ACTION_INTERLOCKS (synonym), PAY_ASSIGNMENT_ACTIONS (synonym), PAY_JP_PRE_TAX (view), and PAY_PAYROLL_ACTIONS (synonym). The view text itself joins PAY_PAYROLL_ACTIONS (alias ppa) to PAY_ASSIGNMENT_ACTIONS (alias paa) on payroll_action_id, and then to PAY_JP_PRE_TAX (alias ppt) on assignment_action_id. The correlated subqueries reference additional instances of these same objects, plus PAY_ACTION_INTERLOCKS to detect unresolved interlocks that would invalidate a future YEA record. FND_NUMBER is a common Oracle EBS utility package used for numeric conversions and validations in such views. The presence of PAY_JP_PRE_TAX as a referenced view (rather than a base table) indicates that this object itself builds on a lower-level Japanese pre-tax abstraction.

Key Columns

  • business_group_id — Business group owning the payroll action, used for multi-organization and security filtering.
  • itax_organization_id — Income tax organization identifier relevant to the Japanese tax filing unit.
  • effective_date / date_earned — Effective date of the payroll action and the date the earnings relate to, key for period and year grouping.
  • assignment_id / assignment_action_id — Identifiers linking the record to a specific employee assignment and its assignment-level action.
  • action_sequence — Sequence number used in the correlated subquery to determine the earliest qualifying action.
  • salary_category — Restricted to YEA and RE_YEA, distinguishing normal year-end adjustment from related or re-adjustment records.
  • itax_category — Japanese income tax category, one of M_KOU (monthly high), M_OTSU (monthly standard), D_KOU (daily high), D_OTSU (daily standard), or D_HEI.
  • itax_yea_category — Year-end adjustment category carried from the pre-tax source, supporting YEA reporting.

Common Use Cases and Queries

This view is typically queried for Japanese payroll audit, YEA reconciliation, and tax reporting. A representative query retrieves YEA pre-tax records for a given assignment and year:

SELECT assignment_id, assignment_action_id, effective_date,
       salary_category, itax_category, itax_yea_category
  FROM apps.pay_jp_pre_itax_v
 WHERE business_group_id = :p_bg_id
   AND to_char(effective_date,'YYYY') = :p_year
   AND salary_category IN ('YEA','RE_YEA');

Because the view already excludes future YEA assignment actions in the same tax year, it is well suited to identifying the operative year-end adjustment action for reconciliation against payroll register output. Reporting teams also use it to validate that completed actions (status C) carry the expected itax category for the organization before submitting Japanese statutory files. Note that the underlying tables are synonyms and the object is owned by APPS; responsibility-specific security via business_group_id should always be applied.