Search Results entry_processed_flag




Overview

APPS.PAY_JP_SOE_RETRO_ENTRIES_V is a supplementary database view within the Oracle E-Business Suite (EBS) Payroll module, owned by the APPS schema and registered under FND Design Data object PAY.PAY_JP_SOE_RETRO_ENTRIES_V. Its status is VALID in both Oracle EBS 12.1.1 and 12.2.2. The view is specifically tied to the Japanese Statutory Occurrence Entry (SOE) retroactive processing functionality implemented through the PAY_JP_SOE_PKG package. The view type designation as "a supplementary view used to simplify forms coding" indicates that it exists primarily to support the Japan SOE forms rather than to serve as a public reporting interface. Oracle explicitly warns that querying or altering data using this view is not recommended, as its structure may change dramatically in subsequent minor or major releases. Despite this warning, the view is frequently referenced by technical consultants when investigating retroactive element entry processing, particularly when tracing the value of ENTRY_PROCESSED_FLAG — the column most commonly searched in relation to this object.

Underlying Base Objects

The view is defined over, and derives its data from, a set of core Payroll and FND base objects. These include PAY_ASSIGNMENT_ACTIONS, which stores assignment-level action records; PAY_ELEMENT_ENTRIES_F, which holds element entry headers; PAY_ELEMENT_ENTRY_VALUES_F, which stores the individual input values associated with each entry; PAY_ELEMENT_LINKS_F and PAY_ELEMENT_TYPES_F (with its translation table PAY_ELEMENT_TYPES_F_TL), which supply element definition and reporting name information; PAY_INPUT_VALUES_F, which defines the input value metadata; PAY_PAYROLL_ACTIONS, which provides payroll action context; and FND_CURRENCY, referenced for currency code resolution. The package PAY_JP_SOE_PKG is also a documented dependency, reflecting the tight coupling between this view and the Japanese SOE processing logic. Notably, APPS.PAY_JP_SOE_RETRO_ENTRIES_V is not referenced by any other database object, confirming its role as a terminal presentation-layer view rather than a dependency for other code.

Key Columns

The view exposes thirteen columns. CREATOR_ACTION_ID and ASSIGNMENT_ACTION_ID are numeric identifiers linking the row to the originating assignment action. ELEMENT_TYPE_ID identifies the payroll element type. ELEMENT_ENTRY_ID uniquely identifies the element entry, while INPUT_CURRENCY_CODE carries the currency of the associated input value. EFFECTIVE_START_DATE and EFFECTIVE_END_DATE define the date range for which the entry is valid. REPORTING_NAME provides the translated element reporting name (up to 80 characters) drawn from PAY_ELEMENT_TYPES_F_TL. PROCESSING_PRIORITY and SUBPRIORITY control the order in which retroactive entries are processed. PAY_VALUE and D_PAY_VALUE hold the stored and display forms of the value. The ENTRY_PROCESSED_FLAG column — the focal point for most searches against this view — is a VARCHAR2 field that indicates whether the retroactive entry has been processed by the SOE logic, making it central to reconciliation and troubleshooting queries.

Common Use Cases and Queries

Typical use cases involve auditing retroactive SOE entries for a given assignment action and identifying which entries remain unprocessed. A representative query is:

  • SELECT element_entry_id, reporting_name, pay_value, entry_processed_flag FROM apps.pay_jp_soe_retro_entries_v WHERE assignment_action_id = :action_id AND entry_processed_flag = 'N'; — to isolate entries awaiting processing.
  • SELECT assignment_action_id, COUNT(*) FROM apps.pay_jp_soe_retro_entries_v GROUP BY assignment_action_id; — to profile retroactive entry volumes.
  • SELECT * FROM apps.pay_jp_soe_retro_entries_v WHERE processing_priority = 1 ORDER BY subpriority; — to review processing order.

Because the view is forms-oriented and subject to structural change, queries should be treated as diagnostic rather than as a stable integration interface.