Search Results pay_jp_isdf_entry_dml_v




Overview
Explore in AI Chat

Overview

The view PAY_JP_ISDF_ENTRY_DML_V is an Oracle E-Business Suite database object owned by the APPS schema and documented as a VALID view within the Payroll (PAY) product family. Per the ETRM metadata, its stated purpose is narrow and explicit: it is used for Japanese localization only. It is not a global payroll object and should not be treated as a general-purpose inquiry view for non-Japanese legislation.

The suffix _DML_V signals that the view is intended to support Data Manipulation Language operations rather than read-only reporting. Because the view exposes ROWID alongside the base table columns, it is structured to allow Oracle Forms and concurrent-style DML transactions to update rows through the view against the underlying PAY_ACTION_INFORMATION table. This design pattern is common in EBS localization layers, where a view provides an application-friendly projection over a flexfield-style action information store, and the preserved ROWID preserves the ability to write back to the source row. The view therefore functions as an integration and maintenance surface for Japanese statutory insurance and pension data captured as action information entries, rather than as a denormalized reporting convenience.

Underlying Base Objects

The documented referenced base object is PAY_ACTION_INFORMATION, accessed through a synonym. The view text is a direct projection of that table: SELECT ROWID, ACTION_INFORMATION_ID, OBJECT_VERSION_NUMBER, ACTION_CONTEXT_ID, ACTION_CONTEXT_TYPE, ASSIGNMENT_ID, EFFECTIVE_DATE, ACTION_INFORMATION_CATEGORY, ACTION_INFORMATION1 … ACTION_INFORMATION25, LAST_UPDATE_LOGIN, LAST_UPDATED_BY, LAST_UPDATE_DATE, CREATED_BY, CREATION_DATE FROM PAY_ACTION_INFORMATION. This confirms a one-to-one structural relationship: no joins, filters, or aggregations are applied, and no localization-specific predicate restricts the rows at the view level. Category and context filtering, where required, is left to calling code.

The metadata lists ASSIGNMENT_ACTION_ID among the exposed columns even though the view text selects ACTION_CONTEXT_ID; this reflects the flexible mapping between the action information context and the assignment action, and explains why both identifiers appear in the column inventory. Consumers should verify the actual column-to-flexfield-segment mapping in the target instance before relying on any single ACTION_INFORMATIONn position.

Key Columns

The most significant columns carry Japanese statutory insurance semantics. The documentation exposes LIFE_GEN_INS_PREM and its _O counterpart (life general insurance premium), LIFE_PENS_INS_PREM / _O (life pension insurance premium), NONLIFE_LONG_INS_PREM / _O and NONLIFE_SHORT_INS_PREM / _O (non-life long-term and short-term premiums), EARTHQUAKE_INS_PREM / _O (earthquake insurance premium), SOCIAL_INS_PREM / _O and MUTUAL_AID_PREM / _O (social insurance and mutual aid premiums), NATIONAL_PENS_INS_PREM / _O, and SPOUSE_INCOME / _O. The _O variants conventionally hold the original or overridden value alongside the calculated value.

Control and audit columns include ACTION_INFORMATION_ID (primary key), OBJECT_VERSION_NUMBER (optimistic locking), ASSIGNMENT_ID, ASSIGNMENT_ACTION_ID, EFFECTIVE_DATE, ACTION_CONTEXT_TYPE, and ACTION_INFORMATION_CATEGORY. The INS_* and IS_* columns (INS_DATETRACK_UPDATE_MODE, IS_ELEMENT_ENTRY_ID, IS_EE_OBJECT_VERSION_NUMBER) support the datetrack and element entry linkage required for retroactive payroll processing. Standard WHO columns complete the row.

Common Use Cases and Queries

Typical usage covers validation of deduction premiums, reconciliation of insurance amounts against payroll element entries, and localization support during Japanese payroll close.

  • Verify current premiums for an assignment: SELECT ACTION_INFORMATION_ID, ASSIGNMENT_ID, EFFECTIVE_DATE, SOCIAL_INS_PREM, NATIONAL_PENS_INS_PREM, SPOUSE_INCOME FROM PAY_JP_ISDF_ENTRY_DML_V WHERE ASSIGNMENT_ID = :p_assignment_id ORDER BY EFFECTIVE_DATE DESC;
  • Identify records requiring correction before a datetrack update: SELECT ROWID, ACTION_INFORMATION_ID, OBJECT_VERSION_NUMBER, IS_DATETRACK_UPDATE_MODE FROM PAY_JP_ISDF_ENTRY_DML_V WHERE ACTION_INFORMATION_CATEGORY = :p_category;
  • Audit changes by user and timestamp: SELECT ACTION_INFORMATION_ID, LAST_UPDATED_BY, LAST_UPDATE_DATE FROM PAY_JP_ISDF_ENTRY_DML_V WHERE LAST_UPDATE_DATE >= :p_since;

Because the view preserves ROWID and is DML-enabled, updates issued against it affect PAY_ACTION_INFORMATION directly; appropriate concurrency and datetrack handling must be ensured. Access should be confined to Japanese localization processing.