Search Results pay_jp_isdf_emp_dml_v




Overview
Explore in AI Chat

Overview

PAY_JP_ISDF_EMP_DML_V is a database view owned by the APPS schema in Oracle E-Business Suite, residing within the PAY (Payroll) product family. As documented in the ETRM metadata, this view is used exclusively for Japanese localization. Its internal name — ISDF, referring to the Interface for Social & Labor Insurance and Dependent information for the Japanese statutory reporting framework — indicates that it supports the data manipulation and reporting layer required to populate Japanese social insurance declaration forms and related regulatory outputs.

The view is catalogued with a status of VALID in both Oracle EBS 12.1.1 and 12.2.2, and its definition is remarkably compact: it projects a fixed set of columns from the PAY_ACTION_INFORMATION table, exposing the underlying ROWID as ROW_ID. Because the view is defined over a single base table and is not declared WITH READ ONLY, it retains the updatability characteristics of a key-preserved single-table view, meaning DML operations can potentially be issued against it — a design consistent with its _DML_V suffix, which signals that it is intended to serve as a data manipulation interface rather than a purely read-only reporting construct.

Underlying Base Objects

The sole documented base object is PAY_ACTION_INFORMATION, accessed through a synonym in the APPS schema. The view's SELECT statement draws all of its columns directly from this table, with no joins, unions, or aggregation. PAY_ACTION_INFORMATION is the generic repository that stores flexible, category-driven attribute data attached to assignment actions. Each row represents one action information record, keyed by ACTION_INFORMATION_ID, and categorized via ACTION_INFORMATION_CATEGORY, with up to a documented set of numbered flexfield-style slots (ACTION_INFORMATION1 through ACTION_INFORMATION7 in the documented view text).

Because the view references only this one table, it is fully key-preserved with respect to PAY_ACTION_INFORMATION. This structural simplicity is what enables the DML-oriented naming convention: the view can act as a controlled entry point through which Japanese localization processing inserts, updates, or reclassifies action information rows without exposing the full base table.

Key Columns

  • ROW_ID — The physical ROWID of the PAY_ACTION_INFORMATION row, surfaced under the alias ROW_ID to give callers a stable handle for row identification and DML targeting.
  • ACTION_INFORMATION_ID — The primary key of the underlying record; the unique identifier for each action information entry.
  • OBJECT_VERSION_NUMBER — The standard EBS optimistic locking column, used to detect concurrent modification of the same row.
  • ACTION_CONTEXT_ID / ACTION_CONTEXT_TYPE / ASSIGNMENT_ID / EFFECTIVE_DATE — Contextual attributes that tie the record to a specific action context, assignment, and effective date, forming the logical addressing of the action information.
  • ACTION_INFORMATION_CATEGORY — The category discriminator that determines how the numbered ACTION_INFORMATION slots are interpreted. In the Japanese localization, this drives which ISDF-related field set applies.
  • ACTION_INFORMATION1 through ACTION_INFORMATION7 — The generic value slots whose meaning depends on ACTION_INFORMATION_CATEGORY.
  • LAST_UPDATE_LOGIN, LAST_UPDATED_BY, LAST_UPDATE_DATE, CREATED_BY, CREATION_DATE — Standard EBS audit columns present on the row.

The documented column list additionally references descriptive attributes such as EMPLOYEE_NUMBER, LAST_NAME_KANA, FIRST_NAME_KANA, LAST_NAME, FIRST_NAME, POSTAL_CODE, and ADDRESS. These represent the Japanese employee name (including phonetic kana forms) and address detail expected on ISDF submissions, and are obtained through the view's use in the localization flow rather than from literal columns in the documented view text.

Common Use Cases and Queries

Typical usage falls into three categories: extraction of action information for Japanese statutory forms (social insurance and dependent declarations), diagnostic inspection of flexfield values for a given category, and controlled DML through the view against PAY_ACTION_INFORMATION.

To inspect records for a specific category:

  • SELECT ROW_ID, ACTION_INFORMATION_ID, ASSIGNMENT_ID, EFFECTIVE_DATE, ACTION_INFORMATION_CATEGORY, ACTION_INFORMATION1, ACTION_INFORMATION2 FROM APPS.PAY_JP_ISDF_EMP_DML_V WHERE ASSIGNMENT_ID = :p_assignment_id ORDER BY EFFECTIVE_DATE DESC;

To review audit metadata for recently changed rows:

  • SELECT ACTION_INFORMATION_ID, LAST_UPDATED_BY, LAST_UPDATE_DATE, OBJECT_VERSION_NUMBER FROM APPS.PAY_JP_ISDF_EMP_DML_V WHERE TRUNC(LAST_UPDATE_DATE) > SYSDATE - 30;

To drive an update safely using the version column:

  • UPDATE APPS.PAY_JP_ISDF_EMP_DML_V SET ACTION_INFORMATION1 = :p_value, LAST_UPDATE_DATE = SYSDATE WHERE ACTION_INFORMATION_ID = :p_id AND OBJECT_VERSION_NUMBER = :p_ovn;

In all cases, callers should confine access to the APPS schema, respect the optimistic locking semantics implied by OBJECT_VERSION_NUMBER, and recognize that the business interpretation of the ACTION_INFORMATION slots is wholly dependent on ACTION_INFORMATION_CATEGORY as defined by the Japanese localization.